Swift By Deya

Any seasoned iOS engineer who uses Xcode can see that it lacks a lot of git features, which is OK as it’s not mainly a source control application.

We can see only primitive features there, which may suffice for personal or small projects, but if you are working on a larger team, you will find it very difficult and sometimes impossible to use source control using the IDE only.

Some Engineers may also notice that markers near files like “A”, “M” and “C” etc.. are stuck most of the time too, so you wont be able to directly tell about file statuses if they are added, modified, conflicting, etc..

Convincing backend engineers to use the terminal will be easier, because GUI will not automatically update repo’s trunk on a server daily at 1:30 AM, but a cronjob that deals with the CLI can easily do this, on the other hand, convincing a mobile developer about this can be a bit more more difficult, because the need for this is not easily demonstrated.

I will start directly with discussing few real life examples.. I’m sure I can think of dozens of cases, but let’s keep this post small.. I will list the commands I use, so you can have an idea about the more power we can have in terminal.

1- PR Reverts: a feature introduced by Github, PR reverts, say you have an already merged pull request, and you want to revert it before a tight-deadline like a branch cut, using Github’s revert feature will not ask about details of commits to be removed, it most probably will remove commits that were merged in the PR, so you may easily end up removing extra stuff that is irrelevant by accident.

But using such command, you will have fine-grained control about what commit to remove or keep.

git revert --no-commit someHash

2- Submodules: if you have nested git repos (submodules), such feature maybe not be existent in most GUI tools.

I normally have terminal open all day, and I can’t live without it 🧐, I hate to push buttons without knowing exactly what each button does, tools can come and go, the CLI will be always what GUI tools are built on.

It’s convenient to set up install scripts, build scripts, deploy scripts, etc.. when working on a large team, one will have no idea what exactly happens in the GUI based app, and in the old times I’ve seen colleagues do bad things impossible to restore without the CLI 🤦🏻.

I feel several times faster using the command line than clicking through with a mouse.

GIT GUI tools were meant to mitigate complexity, but to me, they seem to add more complexity if the project is large, I once seen non-git standard terminology, which normally makes things harder in general.

PS: the only real use of source control in Xcode is the diffing tools, it visualizes diffs perfectly. 🤓

git add

git annotate

git bisect

git blame

git checkout

git checkout -b

git cherry-pick

git clean -fdx

git clone

git clone –single-branch

git commit

git commit –amend -m “New commit message.”

git config

git diff

git diff –check

git fetch

git gc

git init

git log

git log –all

git log –oneline

git log –summary

git log -p

git merge

git pull –rebase

git push

git push –set-upstream origin

git push -u origin feature_branch_name

git rebase

git remote -av

git remote add

git reset –hard

git restore

git revert

git rm

git shortlog

git show

git stash

git stash list

git stash pop

git status

git tag

git worktree

This is not directly related to swift or iOS, but thought it’s worth sharing, since I couldn’t find any article that mention such way to backup files.

I’m one of the people who once used floppies to backup html pages, (3DMax Tutorials back then) from internet caf’es back in 2003, then came CDs, then came DVDs, I also remember the first flash drive my father got me as a teenager, it was 128 MB, this was not affordable for most of the people, now more than 1000x sized SSDs are way cheaper.

The common solutions are google drive & dropbox, they offer (2TB plan) that are $10 monthly, but I prefer to use my own mountable drive with a CDN, to distribute my files with ease, the best way I found to store my work, was storing it on a digital ocean space (similar to AWS S3), and use a client (like cuber-duck) on my mac to directly mount it, or on any device I have.

Pros & Cons

Pros

Direct links!

Economic, it starts with 5$

Saved bandwidth, Content Delivery Network is easily setup, where you can save big amounts of transfer without crossing the caps.

Total control on meta data and content type of files, etc… for example, you can specify if an uploaded mp4 is streamable or downloadable.

Easily mounted into any device or server.

Your files are served, and not just stored, for instance, you can host an angular website on it, without having load on your server.

You can mask the url, to reflect your domain, which is more professional for clients, when doing demos.

Cons

– Can require some technical knowledge at first for some people.

– Most of the desktop clients to mount such drives are not opensource nor free.

– Files cannot be shared with specific people, they are either public or not.

Use cases are infinite:

– for example, if you do scraping, I was able to download few huge youtube channels as a background job on the server, without consuming my internet plan, without keeping some device downloading, and without having to store files locally, they are stored directly there 🧐.

– it works like a NAS (Network attached server), or as a media center.

One Monday morning, some new developer (Penguin 🐧) started their first new job as a software engineer, the chat between two developers (Penguin 🐧) and their team leader (Rex 🦖) went like this.

(Penguin 🐧): I have noticed that we have test cases written for almost all features in our mobile app, why would we write unit tests if we have QA team that does the testing and quality assurance?

(Rex 🦖): Yes, writing unit tests does not only guarantee that features behave correctly just after being developed / shipped, it also guarantees that when someone write any relevant code of new feature, it does not break any existing or any piece of code.

the QA team can never test everything all over again when some new feature is introduced, it’s like an investment, you spend extra time writing unit tests during developing a feature, but prevent any potential bugs from happening in the future.

A CI/CD job running all tests will prevent any developer from merging a code that breaks an existing feature (in case that feature has well written tests), there are other benefits, like tests can be a good documentation too for anyone intending to read your code.

(Penguin 🐧): my first function I wrote is about (application force update) checking, it compares a string that resembles an application version like 1.0.2, and compares it with another version like 1.1.2 to check if the app needs force update or not.

so my responsibility would be checking against all the values of minimum value 000.000.000 up to 999.999.999 value, for both target and current versions, so my test function should iterate through all possible cases, right?

(Rex 🦖): No!!, the idea of test cases, is that covers edge cases, and maybe un-expected cases like minus numbers in this example, and maybe few random usual cases, maybe have these test functions…

testWhenCurrentVersionIsLessThanRequiredVersionRequiresUpdate
testWhenRequiredVersionIsEqualToCurrentVersionRequiresNoUpdate
testMaximumMajorNumberComparesCorrectly
testMaximumMinorNumberComparesCorrectly
testMinimumPatchNumberComparesCorrectly
testMinimumMajorNumberComparesCorrectly
testMinimumMinorNumberComparesCorrectly
testMinimumPatchNumberComparesCorrectly
testMinimumNumbersComparesCorrectly
…. + some random normal cases…

keep in mind, the naming convention should show the intention of the developer, even if the test function name becomes lengthy.

covering all the cases, will cause tests to take long time, maybe few minutes in your case, you must totally avoid that, remember the unit tests criteria? the way you do it will break the first criteria “Fast”, the normal time for tests is something like 50ms or something.

Unit Tests Criteria “F.I.R.S.T”:
Fast: we can run dozens of them in a second, if not more
Isolated: should not depend on each other, or any external state.
Repeatable: they should always give the same result when they are run, like a pure function.
Self-Verifying: the test must unambiguously say whether it passed or failed, with no room for interpretation.
Timely: they should be written before or alongside the production code that you are testing.

(Penguin 🐧): But we must have high test coverage, like 100% coverage to cover all cases, don’t we?

(Rex 🦖): Test coverage means coverage on the code logic itself, like the percentage of lines tested, not on the “possible values coverage”, and by the way, test coverage is a flawed metric, it only means we have test functions that call our code, it does not mean that the test functions are good.

(Penguin 🐧): Good, yeah, any other benefits for having unit tests?

(Rex 🦖): Testing reduces maintenance costs and therefore quantity of bugs, there are also other costs to consider like customer impact, the longer an issue goes undiscovered, the more expensive it is, which can result in negative reviews & lost trust, and of course lost money!

(Penguin 🐧): But why follow TDD (Test Driven Development) methodology? why write the tests before writing the feature itself?

(Rex 🦖): There are a lot of other development methodologies, like TDD, ATDD, DDD, BDD, .. these are lengthy topic, I encourage you to read about them quickly, and the RGR lifecycle of TDD.

(Penguin 🐧): That’s really cool, how can I make sure my code is testable? and what makes it not?

(Rex 🦖): You may consider architectural patterns, that make code more separated and easily tested, like MVVM, VIPER, VIP, …, FRP may make your code easier to test, using dependency injection, and coordinator pattern, using pure functions, etc…

(Penguin 🐧): So I always need to mock stuff when testing, right?

(Rex 🦖): No, Mocks are type of test doubles, there are also Fakes, Stubs, Spies, Dummies, look them up, and know when to use each, they are so confusing at first.

(Penguin 🐧): what other tips do you have?

(Rex 🦖): yes, there are a few on top of my head

- In network testing for mobile in general, no HTTP request should be made, you test the networking feature it self.

- tests run alphabetically, you should not rename your tests to change their order of running, remember that tests should be independent, changing the order intentionally will break this criteria.

- Xcode provides performance tests, that compares between previous runs, where you can also change the baseline, it also gives nicely formatted test coverage markers.

- Writing no tests is better than writing flaky tests!