View Single Post
Old 21 Jun 2021, 07:58 (Ref:4057545)   #32
Akrapovic
Veteran
 
Akrapovic's Avatar
 
Join Date: Mar 2015
Scotland
Posts: 10,912
Akrapovic is the undisputed Champion of the World!Akrapovic is the undisputed Champion of the World!Akrapovic is the undisputed Champion of the World!Akrapovic is the undisputed Champion of the World!Akrapovic is the undisputed Champion of the World!Akrapovic is the undisputed Champion of the World!Akrapovic is the undisputed Champion of the World!Akrapovic is the undisputed Champion of the World!Akrapovic is the undisputed Champion of the World!Akrapovic is the undisputed Champion of the World!Akrapovic is the undisputed Champion of the World!
Hybrid applications tend to have a single codebase, that either spits out an Android and iOS app at the end, or provides a single app that works on both. So you really only have one codebase to look after, which means it'll probably be quicker to develop the app, and you're only maintaining one codebase after it.

The downside of the hybrid applications is they tend to be slower performing than native applications, since you're not using the products exactly the way Google and Apple intended. You also tend to not get the latest and greatest features - so AR for example. Granted, neither of those are really an issue for TRL as it's a very lightweight app, and I won't be using hardcore new features. Although you're only maintaining one codebase, it will probably be harder to maintain - as Android and iOS change, it's going to break your third party hybrid app. Whilst if it's written in native Swift (iOS) and Kotlin (Android), it will most likely be backwards compatible for many years.

For me, it was because I'd done things backwards. I never intended on building an Android app (I'm an iOS developer really), but because I had so many requests I couldn't ignore it. The iOS app was already released, so I had the choice of do a hybrid app for Android (and either keep or bin the iOS app), or do Android 'properly' with Kotlin, so it was done properly - with the help of a much more experienced developer than me.

Im hoping it being built in Kotlin means I won't have to do any major re-writes of the Android version any time soon!

On a kinda related techy note, it's been interesting doing development on both platforms and seeing the pros and cons of both.

Apple Pros:
- The tools are incredible. They literally do just work. Download Xcode and just start
- The framework I used (SwiftUI) is super slick and simple to use.
- OS support is amazing. My app works all the way down to the old iPhone 6S

Apple Cons:
- Expensive. £100 a year just to be a developer
- Some frameworks (StoreKit especially) need some serious updates
- Not a very flexible app store system. You don't have many options available to you.

Android Pros:
- App submission is faster. The submission and approval process is almost immediate, unlike several days for Apple
- Cheaper. £30 a year to be a developer
- The Play Store submission has so many options it's unreal. A/B testing, incredible analytics, etc

Android Cons:
- Android Studio barely works, and the simulator doesn't. You HAVE to have a physical device to work on
- The Play Store has lots of options, but some don't work, and the layout is a mess
- OS support is terrible. There are people with 2 year old devices that can't run my app because they run Android 9

It's funny. The systems are what you'd expect from the 2 sides, even as a developer. Apple is more expensive, but it works beautifully - but it forces you down certain routes with how you build things. Android is scruffy, but god damn the amount of options you have available to you is amazing - you have complete freedom.

Overall I prefer the Apple system, but it's obvious why many would prefer Android.
Akrapovic is online now  
Quote