Thoughts about IOS and Android Native development

In Oct of 2019 I passed the Google Android Developer Certification Test. I was super excited at the time as it would help open doors to many high paying Android jobs, so I kept constantly building apps to boost my portfolio.

The first job offer I accepted however was not in Android, it was with React and while I tried hard to keep building Android apps when I had free time, It slowed down greatly.

Then in 2021 a local non profit business came to me with an interesting proposition for an app they wanted. This app would require me to design layouts, implement a backend, and finally after all this time work in Android again. There was a catch though I also had to build an IOS version for their Iphone clients. So the following list is a few of my thoughts regarding Android and IOS and the possibility of a multiplatform tool.

Update(11-29-2022) System Design Note

This project uses a 2 layer distributed architecture with client side caching, remote Authentication and document based persistent datastore Firebase allowing for Horizontal scaling and growth.
Built to handle 3000 concurrent users or approximately 200 unique teams per Geographical region.

Multiplatform thoughts

1. Kotlin multiplatform appears great on the surface, but that is only if you are using it like a backend service for fetching, storing and sending data. As soon as I tried to use libraries designed to supoort either Android or IOS native there were lots of road blocks and a large lacking of documentation for implementing them with kotlins multiplatform.

2. React native and flutter would have been an ok choice, but they do have a lot less control of what you can do with the apps and occassionally you need native platform level depth quality and they just didn't have it.

Native Platforms for Android and IOS thoughts

SwiftUI/IOS

1. Love this language and documentation, its object oriented and has a plethora of examples making it very easy to find what you need most of the time.

2. Probably should have refreshed myself with the kotlin/android side of phone apps before jumping into IOS. The biggest reason being patterns and principles can be applied accross platforms when the platforms are similar and your knowledge is up to date.

3. SwiftUI doesn't always let you know when and why a library feature was deprecated, so supporting multiple software versions of IOS can become tricky. Especially if they haven't updated official tutorials from apple regarding that libraries usage.

4. I really like the swiftui preview, but during minor errors like syntax and not seeing it update can be frustrating since they can hide the errors even after hitting rebuild.

5. Not having a local db for IPhone like Android can, was surprising. Swifts struct and Observable pattern is great when you get used to it, but coming from the Android side of things it felt like magic for a while for persisting data between pages.

Android/Kotlin

1. I chose Kotlin as it was becoming more popular and compiles down into Java, I can say I am fairly impressed at how much simplier it was then using pure Java.

2. After having a fairly good time with swiftui, I became frustrated with some of Androids methods, especially the build dependencies needed to use jet pack libraries, which I thought would be part of the Android ecosystem by now.

3. Libraries are becoming a pain to deal with, there is a major repo that is forcing everyone to convert their artifacts to a new location because they are shutting down, and since the most popular libraries haven't migrated for some tools its hard to find replacements.

4. Documentation regarding patterns, I like the MVVM pattern and learned it from Google's tutorials and as I was implementing, my app kept kept getting more complicated so I tried out other patterns like repository pattern alongside of MVVM. the biggest issue with some of the new patterns is they are limiting, if I use the repository pattern to handle network calls and update my local DB it becomes difficult to notify my user when an error has occurred. Of course you can pass down fragment application context to the repository in order to populate toasts, but at that point I might as well just be doing the network call closer to the fragment in the View Model. So in summary the patterns can be useful, but tutorials should be more in-depth with real world practices to overcome the limits of said pattern.

Bonus Firebase/Firestore, Google Analytics, and Google Admobs

1. Firebase is a really nice site that allows you to see your backend services easily.

2. Firebase authentication and library helpers is well documented for both IOS and Android making it quick to implement.

3. Firestore takes a minute to learn, but after getting used to a document storage instead of pure sql is and the helpers it provides for protecting your DB, it is something I would recommend all phone app developer to use.

4. Google analytics sounds great but does almost nothing for helping find real time crashes, apparently you have to sign up for crashalytics seperately and may not even be worth it without the custom log statements from google analytics.

5. Admob is an interesting service, I liked how easy it was to implement in a central location on SwiftUI/IOS but I didn't like how on Android I was re-typing my admob unique key in multiple places.

Thank you for reading

I appreciate you taking the time to read, these are just some of my thoughts I wanted to write out as I am coming up to the completion of my current project and it felt nice to get them off my chest.