Skip to main content

Android with Kotlin, iOS with Swift, Kotlin Native, flutter.io, React Native, PWA, Xamarin, Hybrid - which way to go?

Currently there are tons of frameworks how to get your business model to the user... and in the app store
  • Full Native
    • Android with Kotlin, iOS with Swift
    • Deepest integration
    • Single way to make sure that you have no lock-in effect with a framework, and you are f**ed, when Apple or Google disallows the usage of a specific technology...
    • Two teams required
    • 2x code
  • PWA (Progressive Web App)
    • Write offline- and push-capable PWA with web-technologies only
    • Some native features might require hybrid native development and bridging (like In-App purchases, AR, ...)
    • In best case:
      • One web team only for website and app
      • Maybe some native specialists for special features
  • Kotlin Native
    • Develop a shared framework with or without UI using Kotlin Native
    • Additional native code will most probably be required
    • Big Android team, small iOS specialists
  • flutter.io (React Native | Xamarin | ... )
    • One codebase (flutter: Dart, React Native: JavaScript, Xamarin: C#)
      • Additional native code will most probably be required
    • flutter.io is supposed to be the next default development platform for upcoming Android-successor Fuchsia - and has a good hype at the moment 
    • Big flutter team with some iOS and Android specialists
      • Or enthusiastic native developers that want to jump on flutter
  • Hybrid
    • Mix of PWA, Web and Full Native where you choose e.g. on a screen or feature-wise level what to use with which technology
    • Mix of Web, Android and iOS specialists
How to make a decision from here?
There is no simple answer to this - the longer you are working with the technologies and teams, the more the context gets into focus rather than the technology itself. You should ask yourself: What is the most suitable technology for my context?
  • What are the planned features and which technologies are mandatory?
  • How can I standout from my competitors?
  • Which skills are in my team?
  • What budget do I have at hands?
  • How fast do I need to move - how much risk can I take (lock-in effect, dropped technology, development speed, quality, ...)?
  • How long-term do I have to plan?
  • Which crew/teams do I have at hands with which skills... and which commitment?
    • Freelance/internal?
    • Technical skills?
  • Do I have an app-only use-case or do I have to maintain a website as well?
After having answered those questions for yourself, head back to the stacks presented above - and choose your weapon.

What do we do at WELT?
Well, we have a full native team staffed already and our native apps have excellent ratings.

For Edition (iOS and Android) we have chosen to go for the (local) hybrid way - so the main application is native code but most of the views are WebViews, showing local HTML for performance and synergy reasons.

For News (iOS and Android) we went fully native, following the Server-driven UI principle:
  • We defined a design language with pre-defined, multi-purpose bricks, having the backend defining the screens and data
  • We shift as much as possible of the business logic to the backend, to avoid double implementation and staying flexible for changes without requiring to do another app release in the App Stores
  • We have a slighty bigger Android/Kotlin crew that takes care not only of the Android client, but also of the backend implementation using Kotlin with Spring Boot
    • We share a Kotlin lib with the Android Client and the backend
    • We are also trying to share the lib with iOS using Kotlin/Native but are not there yet
For us this works out quite nicely and we can move fast, adding more and more flexibility by shifting more and more dynamic logic to the backend.

For you it most probably is a question of your context
😊

Thanks to Anton Averin and Pawl Polanski for your input!

More reads:
Labels:

Comments

Post a Comment

Most Favorite Posts

How to link to TestFlight App in iOS

There are two things you need to do. First, check to see if TestFlight is installed. Then create a new link to your app. NSURL *customAppURL = [NSURL URLWithString:@"itms-beta://"]; if ([[UIApplication sharedApplication] canOpenURL:customAppURL]) {     // TestFlight is installed     // Special link that includes the app's Apple ID     customAppURL = [NSURL URLWithString:@"https://beta.itunes.apple.com/v1/app/978489855"];      [[UIApplication sharedApplication] openURL:customAppURL]; } This special https://beta.itunes.apple.com URL will be opened directly in TestFlight. Finally, if you are using iOS 9 (or later), you need to make an addition to your Info.plist to get the canOpenURL: method to work. If your app is linked on or after iOS 9.0, you must declare the URL schemes you want to pass to this method. Do this by using the LSApplicationQueriesSchemes array in your Xcode project’s Info.plist file. For each URL scheme you wan...
Post a Comment
Read more

Working natively with JavaScript in iOS and Android without WebView

Using JavaScript code from native code without using a WebView (sic!) can be really useful to introduce dynamic functionality that was updatable without need of updating the app shorter iteration cycles share code between backend and native iOS and Android apps You can have business logic provided by a JavaScript that then controls the app that inject native functionality in the JavaScript context. You could even write an A/B testing framework based on this approach. iOS iOS offers the native JavaScriptCore: Evaluate JavaScript programs from within an app, and support JavaScript scripting of your app. So you can evaluate a script and read its return value natively: context.evaluateScript(myLib); let result = context.evaluateScript("myFunction();") let myFunction = context.objectForKeyedSubscription("myFunction"); let parametrizedResult = myFunction.invokeMethod(...) Or you can inject a native object into the JavaScript engine: @objc protoco...
1 comment
Read more

Xcode 7.2: Refactoring not supported for Swift... but there is a plugin!

but... there is a plugin for that: Refactorator GitHub
Post a Comment
Read more

Bundeskartellamt prüft Apples Tracking-Regelungen für Dritt-Apps (ATT, App Tracking Transparency Framework)

Das Bundeskartellamt hat gegen das Technologieunternehmen Apple ein Verfahren zur kartellrechtlichen Prüfung seiner Tracking-Regelungen sowie des App Tracking Transparency Framework eingeleitet. Das Bundeskartellamt geht dabei insbesondere dem Anfangsverdacht nach, dass diese Regelungen Apples eigene Angebote bevorzugt behandeln und/oder andere Unternehmen behindern könnten. 14.06.2022 Pressemeldung Bundeskartellamt
Post a Comment
Read more

Validity Time Auto-Renewables in Sandbox

The subscription durations, sandbox durations and incentive durations of auto-renewables. Hint: In Sandbox the validity time differs from live environment!!! Durations Sandbox Duration Incentive Durations (optional) 7 days 3 minutes 7 days 1 month 5 minutes 7 days, 1 month 2 months 10 minutes 7 days, 1 month 3 months 15 minutes 1 month 6 months 30 minutes 1 month, 2 months 1 year 1 hour 1 month, 2 months, 3 months After 6 extensions the abo is cancelled automatically in the sandbox environment.
Post a Comment
Read more

NSURLProtocol

NSURLProtocol is both the most obscure and the most powerful part of the URL Loading System. It's an abstract class that allows subclasses to define the URL loading behavior of new or existing schemes. Intercepting HTTP requests to serve images locally from the app bundle resources, if available Signing outgoing streaming media requests Creating a proxy server for a local data transformation service with a URL request interface Introducing custom schemes (e.g. myapplocalfile://myfile.gif) and intercept them Even the UIWebView class makes request using the default iOS URL Loading System, so you might use custom scheme inside HTML, creating an NSURLProtocol and deliver the response from a local file. NSHipster NSURLProtocol
Post a Comment
Read more

Employee Development ...by Cards ...by Lego Brick Boards

Employee Development by using Skill Cards The goal is to build a hand of cards that make up that person’s most relevant personal growth areas. To do this, both the people leader and team member start with a deck of the same skill cards each. In private, each goes through this deck and sorts these cards into three stacks: not relevant, good enough, and to improve. By discussing why each card was placed where, with particular focus on those that do not match, a real, structured, and to-the-point conversation occurs. By focusing on reasoning—what led you to place this card here?—both can develop a shared understanding of the other's views. The main event, however, comes in focusing on those cards in “to improve”. To create focus and drive actual impact, these cards are discussed and prioritized. With a clear priority and a shared understanding of the individual aspects of each, tangible actions are crafted that can be taken to grow one’s career. LinkedIn Rob Sawyer mobi...
Post a Comment
Read more