Forem: Michael Mavris

How to synchronize versions and build numbers across different targets

Michael Mavris — Sun, 27 Sep 2020 18:21:32 +0000

If you ever developed an extension for iOS, you are most likely to be familiar with the following errors when uploading the app in the App Store:

CFBundleVersion Mismatch - The CFBundleVersion value '1' of extension 'ExtensionApp' does not match the CFBundleVersion value '2' of its containing iOS application 'Main.app'.

CFBundleShortVersionString Mismatch - The CFBundleShortVersionString value '1' of extension 'ExtensionApp' does not match the CFBundleShortVersionString value '2' of its containing iOS application 'Main.app'.

If you have only one extension it's not that difficult to keep them synchronized, but things get tricky when you add more than one extension. In my case, I have a project that has 6 targets and I need to keep the synchronized.

Since we are programmers, and our job is to solve problems, I thought that it must be a better way to synchronize the target's versions! The first thing that came to my mind was to use Run Script Phase but then I thought it will get messy for 6 different targets.

After digging around, I found a much better and much cleaner solution. We will use the User-Defined setting that they will be used by all of the targets. All we have to do is go to the project's Build Settings, click on the plus sign and add two settings and call them APP_VERSION and APP_BUILD.

Adding the User-Defined Settings

You will find the newly added settings at the bottom of the Build Settings tab. Set the APP_VERSION to match the main target's version (eg. 3.4.1) and the APP_BUILD to match its build number (eg.15).

These settings are accessible throughout the project using the $(APP_VERSION) and $(APP_BUILD) variables. Now, we need to go through each target's Info.plist file and set the Build Version value to $(APP_BUILD) and the Build Version String (short) to $(APP_VERSION). From now on, you should be changing the version and the build number from the Build Settings.

That's it!

Happy coding!

Say hello or tweet us!

How to create a white label iOS app (Part 5)

Michael Mavris — Fri, 11 Sep 2020 19:23:29 +0000

On Part4 we discussed how to use .plist files with different values for each target. The .plist approach will help us build the brand for each target, avoiding the boilerplate code.

We couldn't build the brand for each target without discussing the target's app icons. There are two ways to use a different set of App icons and we are going to discuss them both.

You can download the project here as we left it on Part4.

The first and easiest way is to use the Assets.xcassets for every target. Just go to plus sign and select App Icons & Launch Images -> New iOS App Icon and name it TargetName-AppIcon. Then, at the target's General tab and select the TargetName-AppIcon in AppIcon Source. That's it!

The second way is to create a different .xcassets for each target, that will contain only the AppIcon of the specific target. For our project, we are going to create a new asset catalog called TestCoffee.xcassets (under TestCoffee resource folder) with target membership only for TestCoffee target and then we are going to set it as AppIcon Source in its General tab. Now, we have to create an AppIcon called AppIcon. The tricky part now, is to set the appropriate AppIcon for each target. For some reason, Xcode won't let you set it directly but I found a workaround. You need to select "Don't use assets catalog", then select any other file in Xcode and then go back to the target's General tab. You will notice that a new button appeared called "Use assets catalog". Tap on that and select the appropriate asset, then select "Migrate". Now you can select the AppIcon from the specific Asset Catalog. Repeat the same procedure for every target.

The structure for each target

I personally prefer the second way because is a cleaner structure especially if you have a big number of targets.

That's the end of the "White label" series! I hope you found it helpful! If you have any other part that you want me to cover or you want to discuss, please don't hesitate to drop me an email.

You can find the final project here.

Happy coding!

Say hello or tweet us!

How to create a white label iOS app (Part 1)
How to create a white label iOS app (Part 2)
How to create a white label iOS app (Part 3)
How to create a white label iOS app (Part 4)
How to create a white label iOS app (Part 5)

How to create a white label iOS app (Part 4)

Michael Mavris — Fri, 04 Sep 2020 06:56:07 +0000

On Part3 we discussed how to use Preprocessor Flags to change the result of the coffeeDescription function based on which target was executing the function. As I noted, I don't like the Preprocessor Flags solution but it was good example to understand how they work.

You can download the project here as we left it on Part3.

A much better alternative is to use a .plist file (Properties List) for each target. We are going to create a .plist file for each target and we are going to load these properties in the app.

We will create 2 .plist files for our targets, and the name of each file it will be the Bundle ID. The rockandnull.com.TestCoffee.plist will be visible only to TestCoffee target and the rockandnull.com.RealCoffee.plist will be visible only to RealCoffee target (using target memberships).

The objective is to load the properties in the target using a singleton class called PropertiesController.

import Foundation

class PropertiesController {

    static let sharedInstance = PropertiesController()
    var description : String!

    func loadProperties() {
        let bundleID = Bundle.main.bundleIdentifier
        if let path = Bundle.main.path(forResource: bundleID, ofType: "plist") {
            //CAUTION: We are not using best practices for simplicity. Using plain string as a key and force unwrapping is prone to errors.
            if let nsDictionary = NSDictionary(contentsOfFile: path) {
                self.description = nsDictionary["description"] as? String ?? ""
            }
        }
    }
}

The loadProperties function is responsible to load the specific .plist file using the Bundle ID (that's why we named our .plist files after the Bundle ID). Then it converts the .plist file to an NSDictionary and then assigns the value of each key to the specific properties.

We need to load the properties first thing, so we are going to add this code in AppDelegate

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        // Override point for customization after application launch.
        PropertiesController.sharedInstance.loadProperties()
        return true
}

Then we will modify our coffeeDescription function in Coffee class

 static func coffeeDescription() -> String {
      return PropertiesController.sharedInstance.description
 }

The last thing (I promise) to complete this approach is to add a property (String) in rockandnull.com.TestCoffee.plist with the key description and value TestCoffee. Repeat the procedure for RealCoffee and set the value as RealCoffee.

Now we will run the app and we will notice that we have accomplished the same result with the Preprocessor Flags solution.

So, why the fuss? It's a much cleaner solution. In Part3 we had only 2 targets and we used 7 lines of code. Imagine how much boilerplate code we would end up having in a project with 30 targets. With the .plist solution, our function's size will remain the same no matter how many targets we have added.

Also, you can add other types of data in the .plist, like a number, a boolean, a date, etc. I use the .plist approach to store the API endpoint, a copy that is different for each brand and specific color as HEX. This approach will work nicely if you discuss it with your designer and ask him/her to group the project colors in let's say, 6 groups. Then you will create 6 properties and you will assign the HEX code for each color and load them in PropertiesController as we did with description. Now, for each view that you want to set a color you will use the PropertiesController.sharedInstance.Colour1. That's it you can now change the colors of the whole app from the .plist file.

Use with caution! Don't use the .plist approach to store sensitive data. A .plist file is unencrypted and can easily be fetched from a device. I can't stress this enough!

Happy coding!

Say hello or tweet us!

How to create a white label iOS app (Part 3)

Michael Mavris — Sat, 29 Aug 2020 15:17:43 +0000

As we discussed on Part2, it's not recommended to create duplicates of the same class with different target membership.

You can download the project here as we left it on Part2.

We could tackle this issue using Preprocessor flags, which will allow us to add conditions based on which target the app is running. Go ahead and delete the Coffee class under RealCoffee. Then go to Coffee class under the TestCoffee folder and check the RealCoffee target under Target Membership.

Coffee class is now recognised by both targets

Now we need to set an identifier for each Target. Will set this identifier under Build Settings -> Active Compilation Condition for both identifiers. Use TESTCOFFEE and REALCOFFEE for both Debug and Release.

Now head to the Coffee class and modify the coffeeDescription as follows:

static func coffeeDescription() -> String {
     #if TESTCOFFEE
        return "TestCoffee"
     #elseif REALCOFFEE
        return "RealCoffee"
     #else
        return "WRONG"
     #endif
}

It's clear from the code that the response from the coffeeDescription function will depend on the target. If the response is "WRONG" then something went wrong setting the Active Compilation Conditions.

I personally don't like using Preprocessor flags for the coffeeDescription function because it won't scale. Imagine having 30 targets and having 30 Preprocessor flags for each one. I just wanted you to know that you have that option! Use with caution.

Happy coding!

How to create a white label iOS app (Part 2)

Michael Mavris — Mon, 24 Aug 2020 22:06:26 +0000

How to create a white label iOS app (Part 1).

On Part 1 we talked about Targets and how to use them in a white label product, but we noticed a rising problem. We couldn't differentiate (easily) the .plist files for each target. So, we need to create a structure to keep the non-shared files for each target.

You can download the project here.

First, we will create a folder called Resources and then two subfolders called RealCoffee and TestCoffee (physical folders using New Group option), and then we will place each .plist under its corresponding target.

Note: There is an extra .plist file called TestCoffee copy-Info.plist. Please delete it.

Our project directory should look like this:

If you try to build and run the project you will notice that the Xcode is complaining about the Info.plist file. Since we renamed our Info.plist files, Xcode doesn't know where to find them so we need to set the path to the files. We will do that in Build Settings->Info.plist file. Just make sure to use the absolute value of the path. For RealCoffee is RealCoffee-Info.plist and for TestCoffee is $(SRCROOT)/TestCoffee/Resources/TestCoffee/TestCoffee-Info.plist. The reason is that the 2 files are located in different paths. We left it that way to demonstrate the difference.

Our structure is fairly easy to understand. Any file that is bound only to one of the targets, it should fall under the target's folder. To illustrate, click on RealCoffee folder and create an object called Coffee and set the target only to RealCoffee. Then, repeat the procedure for TestCoffee and set the target only to TestCoffee.

Two Coffee files with different target membership

We will create 2 Coffee classes with different implementation in order to demonstrate how the targets interact with the files.

class Coffee {
    static func coffeeDescription() -> String {
        return "TestCoffee"
    }
}

Coffee class for TestCoffee

class Coffee {
    static func coffeeDescription() -> String {
        return "RealCoffee"
    }
}

Coffee class for RealCoffee

Now let us update the coffeeIBAction to call the Coffee static function:

    @IBAction func coffeeIBAction(_ sender: Any) {
        let appName = Bundle.main.infoDictionary?["CFBundleName"] as? String
        let appVersion = Bundle.main.infoDictionary?["CFBundleShortVersionString"] as? String
        self.popUpOptionDialog("",content: "You have ordered coffee using the \(appName!) app with version \(appVersion!) and coffee description: \(Coffee.coffeeDescription())")
    }

Alert view in ViewController

Now, if you run the app you will notice that the result for coffeeDescription() is different for each target.

We have used this example because it's easy to understand the fundamentals, but it's not recommended to create the same class with different target membership. There is a better way and we will demonstrate it in the next part!

Happy coding!
Original Article.

How to create a white label iOS app (Part 1)

Michael Mavris — Sat, 22 Aug 2020 11:02:39 +0000

If you are a developer in a company that is developing software for its products only, then you probably won't be familiar with the "White-label" term.

A white-label app is a product produced by one company then packaged and distributed by other companies under different brands.

Let's say that are going to produce an app for coffee shops. The main functionality will be the same but we want to change the colours, icons, name, etc for each brand.

Targets

So, let's talk about Targets. A target specifies a product to build and contains the instructions for building the product from a set of files in a project or workspace. For example, we can create our TestCoffee app with its files, bundle ID, etc, and then we can create a new Target (called RealCoffee), that it will share the source code with TestCoffee. The name, bundle ID, and some other properties should be different between the two targets but luckily we can differentiate them easily in the Targets.

Let's download the project and get our hands on the project.

As you have already noticed, we have only one Target called TestCoffee. This is our test/abstract environment. Our first customer bought our software solution and it's called RealCoffee. Now, we need to duplicate our TestCoffee target:

Then we rename Display Name and Bundle Identifier to RealCoffee and rockandnull.com.RealCoffee accordingly.

We also need to rename the scheme so it will be easier to match the target with the scheme ( TestCoffee copy should be rename to RealCoffee ).

You probably have already noticed one new .plist file called TestCoffee copy 2-Info.plist that belongs to RealCoffee target, but don't worry we will come back to this later.

Now, run the app using the TestCoffee target and tap the "I want coffee" button. Then, switch to RealCoffee target and tap the "I want coffee". You will notice the popup message is slightly different between the two targets.

This is how easy is to use Targets in your project! Of course, things could get messy pretty fast in a real project, but don't worry, we are here to cover these scenarios in the next parts.

Happy coding!

Quick UI Android tests: Espresso Test Recorder + common modifications

Michael Mavris — Thu, 07 May 2020 16:44:22 +0000

Testing is super important for providing software that is reliable and this is widely accepted. Unfortunately, testing is hard. It requires proper architecture, as well as significant time to write the tests (quite often it takes more time than the actual code).

Espresso tests are the UI integration tests for Android apps. They run on a device or emulator. Normally, you need to write these tests by hand, just like you would with a regular unit test. Android Studio's Espresso Test Recorder is a valuable tool to cut down the time required to write such a test. It's completely visual and provides a great starting point!

To record a test, connect a device or launch an emulator instance, and select Run -> Record Espresso Test in Android Studio. Your app will launch and whatever clicks you make on the emulator/device, they will be recorded.

When you want to verify that something you expect is indeed on the screen, click the Add Assertion button. What is currently on the device screen, will appear in that window. You can click on an element, and assert what you expect.

When you are done, click OK and a Kotlin/Java integration test will appear!

Common modifications needed

Although this looks like magic, it's not. This tool is complementary to writing UI tests. It will output a complete test, but most probably you would need to modify it to make sure it's not flaky and works all the time.

Use fakes/mocks By default the test recorder will use the real implementation of your classes. This means that you will connect to your production instance and make changes to your production data. This is not ideal, to say the least, and would lead to flaky tests (i.e. sometimes the test might pass, sometimes not).

To make your tests hermetic (i.e. self-sufficient tests that produce reproducible results) you would need to replace some parts of your stack with fake implementations that always return the same results (to have reproducible tests). Services that connect to a remote server and return results are the most obvious ones.

An excellent guide for deep diving and a practical example here.

If you don't have a proper architecture for faking out real implementations for fakes, you can use an Espresso test to automate things that you would be testing manually, until you properly refactor your architecture.

Idle resources Another big issue with UI tests and the recorder is that it does not figure out when it should wait before taking a UI action (e.g. clicking a button). While recording the test, the waiting time before clicking on a button is not recorded (e.g. waiting for that spinner to disappear before proceeding is not recorded).

The proper solution is to "teach" Espresso when a resource is ready and action can be taken (more details in the official doc).

An ugly (but working) hack I found some time ago, is to use a custom action and wait for the desired view to appear before proceeding.

class WaitViewAction private constructor(private val viewId: Int, private val millis: Long): ViewAction {

    companion object {
        fun waitId(viewId: Int, millis: Long = 5000) {
            onView(isRoot()).perform(WaitViewAction(viewId, millis))
        }
    }

    override fun getConstraints(): Matcher<View> {
        return isRoot()
    }

    override fun getDescription(): String {
        return "Waiting for $viewId"
    }

    override fun perform(uiController: UiController, view: View?) {
        uiController.loopMainThreadUntilIdle()
        val startTime = System.currentTimeMillis()
        val endTime = startTime + millis
        val viewMatcher = withId(viewId)
        do {
            for (child in TreeIterables.breadthFirstViewTraversal(view)) {
                if (viewMatcher.matches(child)) {
                    return
                }
            }
            uiController.loopMainThreadForAtLeast(50)
        } while (System.currentTimeMillis() < endTime)
        throw IllegalStateException("View waiting timed out")
    }
}

Then use like this: WaitViewAction.waitId(R.id.myButtonView)

Matchers Noticed that the recorder quite often is adding more matching conditions than necessary. Therefore, if you just recorded a test then run it and fails, you might need to manually inspect the code that tries to find and click on elements.

Hopefully, this was a super quick introduction to the Espresso Test Recorder and the common things that you might need to change after you record a test. Happy testing!

How to parse JSON in Swift 5 (with Codable)

Michael Mavris — Sat, 02 May 2020 07:47:15 +0000

Parsing JSON it's a task that you will need to implement almost in every project that interacts with a REST API.

For this example, we are going to use Twitter API to get statuses class.

{
"created_at": "Wed Oct 10 20:19:24 +0000 2018",
"id": 1050118621198921728,
"id_str": "1050118621198921728",
"text": "To make room for more expression, we will now count all emojis as equal—including those with gender‍‍‍ and skin t… https://t.co/MkGjXf9aXm",
"lang": "en",
"user": {
        "id": 6253282,
        "description": "The Real Twitter API. Tweets about API changes, service issues and our Developer Platform. Don't get an answer? It's on my website.",
        "url": "https://t.co/8IkCzCDr19",
        "name":"Twitter API"
    }
}

JSONSerialisation
We have the native option which is to use the JSONSerialisation class method jsonObject(with:options:) which returns a value of type Any. Then you will most probably cast it in [String:Any] in order to access the keys and after getting the value of a specific key you should cast it again.

if let statusesArray = try? JSONSerialization.jsonObject(with: data, options: .allowFragments) as? [[String: Any]],
    let user = statusesArray[0]["user"] as? [String: Any],
    let username = user["name"] as? String {
    // Finally we got the username
}

Continue reading on my personal blog

Into the Flow: Kotlin cold streams primer

Michael Mavris — Thu, 30 Apr 2020 19:02:55 +0000

If you are a regular user in the Kotlin community you must have heard about Kotlin Flows. At least, I've heard about them but never spend the time looking into them. But lately, when I was about to start a new Android project I decided it was finally time to look into them. Maybe everybody was talking about them for a reason.

Why Flows

We already have suspending functions. We could do async operations without blocking, by using suspend fun doSomething(): List<Something> for instance. But that would mean that we need to calculate all the results before starting to process them. Using fun doSomething(): Flow<Something> we can process the results as soon as they are ready in a non-blocking way.

It's Cold Flows actually

You might have noticed that the function returning the Flow does not have the suspend prefix. This is because it returns immediately and doesn't do any processing. The actual work happens when the flow is "collected" (or more generally speaking a terminal operator is applied on the flow), e.g. flow.collect { something -> println(something) }. Every time we call collect, the flow code will be executed again.

It's referred to as "cold", because the flow (or stream if you like) doesn't exist before collect is called and is created again every time collect is called. If the flow was there anyway and we just listened to it, then it would be "hot".

Create and terminate a Flow

The most basic way to create a Flow is using the flow { ... } builder (unexpected, right?)

fun doSomething(): Flow<Int> = flow { 
    for (i in 1..3) {
        delay(100)
        emit(i)
    }
}

A new item in the flow can be "emitted" using emit.

Code inside the flow { ... } builder block can suspend (delay is a suspend function). But, as we said before, doSomething() is not a suspend function and doesn't block.

val something = doSomething()

viewModelScope.launch {
    something.collect { value -> println(value) }
}

On the other hand, collect is a suspend function and needs to run inside a Coroutine Scope.

Other ways to create a Flow include converting regular collections (e.g. listOf(1,2,3).asFlow()) or fixed set of items into Flows (e.g. (1..3).asFlow()).

collect is just one way to terminate a Flow. Other ways include getting the first, ensuring only a single value is emitted, reducing, folding, converting toList, etc.

Transforming Flows

Transforming is quite similar to how you would transform a regular collection. Familiar operators such as map, filter, take exist. I think there are 2 major differences from the regular collection transformation:

Code inside those transformation functions can suspend
You don't have to return a single value, you can call emit as many times as you want using transform:

(1..3).asFlow() 
    .transform { number ->
        emit(number*2)
        delay(100)
        emit(number*4) 
    }
    .collect { number -> println(number) }

Coroutine Scope

When we collect a Flow we are executing a suspend function. This means that both the code inside flow { ... } and inside collect { ... } will run on the current Coroutine Scope. But there are cases we want those 2 code blocks to run in different Coroutine Context (usually to run them in different Dispatchers, for not blocking the Main/UI thread for instance).

We shouldn't use the familiar withContext(Dispatchers.IO) in this case. Flows provide a dedicated flowOn operator for this.

fun doSomething(): Flow<Int> = flow { 
    // This runs on Dispatchers.IO
    for (i in 1..3) {
        delay(100)
        emit(i)
    }
}.flowOn(Dispatchers.IO)

[...]

viewModelScope.launch {
    doSomething().collect { value ->
        // This runs on Main thread and just prints those values
        print (value)
    } 
}

Composing Flows

One of the most powerful things you can do with Flows it to compose them in different ways.

zip them, i.e. combine the 1st item of Flow A with the 1st item of Flow B , etc

val flowA = (1..3).asFlow()
val flowB = flowOf("one", "two", "three")
flowA.zip(flowB) { a, b -> "$a and $b" }
     .collect { println(it) }

// Output:
// 1 and one
// 2 and two
// 3 and three

combine them, i.e. every time a new value is emitted from Flow A combine it with the latest value of Flow B

val flowA = (1..3).asFlow()
val flowB = flowOf("single item")
flowA.combine(flowB) { a, b -> "$a and $b" }
     .collect { println(it) }

// Output:
// 1 and single item
// 2 and single item
// 3 and single item

Flattening Flows

Getting to the situation where a Flow transforms into another "sub"-Flow and you end up with Flow<Flow<X>> is quite common. Similarly to collections, there is a number of flat* operations.

flatMapConcat for waiting for each "sub"-Flow to complete before collecting (i.e. collecting Flows sequentially)
flatMapMerge for collecting whatever item is emitted (i.e. collecting the Flows in parallel)
flatMapLatest for collecting the latest "sub"-Flow that is emitted, while canceling the previous "sub"-Flow

Exceptions

Whatever exception is thrown in flow { ... } or collect { ... } can be caught with regular try - catch statements.

But there is a more declarative way, with the catch operator. Note that when you "catch" the exception, you can emit again, throw, log, etc.

doSomethingThatMightThrow()
    .catch { e -> emit("Caught $e but emitting something else") }
    .collect { value -> println(value) }

Another important thing to remember is that this operator is "upstream" only, i.e. it does not "catches" anything after it's declared.

doSomethingThatMightThrow()
    .catch { e -> emit("Caught $e but emitting something else") }
    .collect { 
        // Something gone wrong here, will not be caught
    }

My impression after looking into Flows is that they can handle more than the basic "cold stream" needs. They are not as comprehensive and powerful as other reactive libraries (e.g. RxJava) but you can always add them to your project later when needed (actually converters between Flows and other reactive libraries are provided).

For those of you wanting to read more on the subject, I would recommend the official docs and these blog posts with insights into the design of Flows (1, 2).

Transferable knowledge

Michael Mavris — Wed, 15 Feb 2017 20:23:50 +0000

This is a story about my knowledge as an iOS Developer and how I transferred that knowledge to a different language and SDK.

The path to become an iOS Developer

Back in 2008 when Steve Jobs announced iOS SDK (I was still studying Computer Science) I made the most important choice of my life so far. “I will become an iOS Developer I thought to myself.

Having no experience as Software Developer, the path to become a professional iOS Developer was not easy at all. Long story short, I landed my first job as iOS Developer two years ago.

My concerns

There is a controversial saying: “Jack of all trades, master of none which I totally agree. It implies that by trying to learn a lot of things, you won't master any of them. I consider myself as “jack of all but not by choice. I previously worked as Systems Engineer for five years and after switching to iOS Developer, I was working on web projects when there was no iOS projects in the queue. So, I can build a full product myself but still, I do not master any of these technologies. So I wanted to focus on iOS only and master that field.

My biggest concern was: What will happen if iOS devices reduced to 1% and no one wants an iOS app? I know I can easily transfer my knowledge to macOS apps but nobody asks for macOS developers in my country. So, what I learned so far will be useless, right?

It depends!

It depends on your experience the time you decided to focus on that specific language and SDK. For example, if you don't have experience in multithreading, working withs GCD, NSOperations, NSThread etc (multithreading in iOS and macOS), will help you understand the concept. If you go deeper you will learn about Race Conditions, DeadLocks, Atomicity etc. On the other hand if you are already experienced with multithreading going deep on GCD or NSOperations, wouldn't be helpful for other languages and SDKs.

From iOS Developer to Mobile Developer

So, I got this offer for Xamarin Developer that I couldn't refuse. I thought that C# is very good language and also I will get the chance to get familiar with Android OS, so why not?

Transferable knowledge

As I said before, Objective-C and iOS were the first language and SDK that I went deep. So, I didn't transfer any knowledge and I learnt everything from scratch.

Software Design Patterns

Coming from university's C style programming I had no idea what Software Design Patterns means(in real software). Creating a couple of projects in Objective-C helped me to undestartand the concept.

Apple is using a poor implementation of MVC in their examples. After building some big projects I realised that Apple's way of building apps (at least how they build their examples) wasn't suitable for me and I looked for alternatives Software Design Patterns. Then I got familiar with MVP and MVVM. I ended up using MVVM.

This kind of knowledge is fully transferable to other languages and SDKs. For example, to build an app for iOS and Android with shared business logic, MVVM is the way to go.

Object Oriented Programming

Again, coming from procedural C, I was using classes as structs in Objective-C. For example, if I had a class Movie and I needed to manipulated the data, I would probably do it in the ViewController. But, as the project was growing, I would need the manipulated data on another ViewController also and I realised that this “logic should be handled by the class.

Object Oriented Programming is also fully trasferable.

Multithreading

Multithreading approaches might be different for each language. There are some low and high level APIs. I didn't go very deep on multithreading in iOS, but I am familiar with Race Conditions, DeadLocks, Atomicity etc. This knowledge can be applied to other languages and SDKs as well.

Mobile way of thinking

The approach for building a mobile app is very different from building a website.

First of all you need to be careful what data are presented to the user. Since the screens are small, there is no need to present unnecessary data in a List View.

You also need to consider the resources of the mobile devices. For example a user might be using cellular data, so downloading 10 MB of data each time your app starts wouldn't be a good idea.

Some other tricks like showing cached data to the user while the new data are beeing downloaded, will keep the user busy without having him/her watching a progress bar.

In this case the knowledge is transferable only because I am moving from mobile to mobile SDK.

Version Control

When I started using Git, I was only using Commit, Push, Pull. Then I learnt about Branches, Tags, Conflicts, Pull requests etc and I developed my own flow. This knowledge is also transferable.

Conclusion

In my case, I was able to transfer about 80% of my knowledge to a new language and SDK. Because I was totally inexperienced before starting as iOS developer, I was able to transfer a lot of basic knowledge. It also helps that I moved from mobile to mobile SDK.

I am still learning new things with C# (like Inversion of Control) that I could apply in other languages in the future.

So, what knowledge you can transfer, depends on your experience and if you are moving to a similar SDK.