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:

Comments

Most Favorite Posts

Server-driven UI (SDUI): Meet Zalandos AppCraft and AirBnB Lona

A short WTF: Joe Birch:  SERVER DRIVEN UI, PART 1: THE CONCEPT Zalando seems to follow the SDUI principle as well - defining a common design language and construct the screens on the backend while displaying them natively on the clients. They even go one step further; they implemented a mighty toolset to enable non-technical stakeholders to define their own native app screens Compass: Web tooling to create screens and bind data Beetroot: Backend service that combines the screen layout definition with the data Lapis/Golem: iOS/Android UI render engines Crazy cool! Good job, guys (when you do an open-source release?) To even move faster a Flutter based UI render engine implementation was great! See also AirBnB Lona SDUI approach Building a Visual Language Why Dropbox sunsetted its universal C++ mobile project and AirBnB its React Native implementation

Judo App - Server Driven UI out of the box

Judo App Judo brings server-driven UI to your iOS and Android apps. Build user interfaces visually in a fraction of time and publish them instantly without submitting to the app store. Build Experiences - With No Code The Judo app for macOS, available through the App Store, is built for design professionals with common keyboard shortcuts and familiar concepts like canvas, layers and inspector panel. Workflow is streamlined with the ability to drag and drop media files directly into your experiences and manage your own Judo files in Finder. Manage Creative Execution A Judo experience is interactive and can include text, images, video and buttons. An experience may be part of a screen, a single screen, or more typically multiple linked screens. Judo supports screen transitions, carousels, horizontal scrolling and modals. Clients can add custom fonts and define global colors and these are updates applied universally. Effortlessly Deploy Judo Cloud syncs your experiences with your iOS and ...

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...

Dark Theme (Dark Mode) in Android WebViews, WKWebViews and CSS

So your apps just implemented a shiny new dark theme and it’s looking 👌 There are lots of benefits to having a dark theme in your application, and having it consistent throughout your application allows for a great user experience. But what happens when the the user runs into a WebView in your app? Support: if (WebViewFeature.isFeatureSupported(WebViewFeature.FORCE_DARK)) { ... } Set: WebSettingsCompat.setForceDark(webView.settings, WebSettingsCompat.FORCE_DARK_ON) Current setting: val forceDarkMode = WebSettingsCompat.getForceDark(webView.settings) Joe Birch Assuming your question is asking how to change the colors of the HTML content you are displaying in a WKWebView based on whether light or dark mode is in effect, there is nothing you do in your app's code. All changes need to be in the CSS being used by your HTML content. CSS dark mode via :root variables, explicit colors and @media query: :root {     color-scheme: light dark;      ...

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.

STF: Open-Source Fastest device testing Smartphone Test Farm for Android

No more trouble Forget having to physically pick up a device ever again. No more learning where the buttons are, or where the power cord goes. Remote control Any device in realtime, using your mouse and keyboard. Or even your own smartphone. Manage inventory See which devices are connected, and who is using which device. Search devices by any specification. From your browser No app installation is required as a user. Do realtime testing on more than one device, using just your browser. Control Multiple Devices As if they were plugged directly to your computer OpenSTF.io GitHub

Implementing UI tests on iOS and Android using screenshot comparison tools

Have you ever thought when writing or maintaining UI tests, there must be a better way? Take a look at screenshot tests provided by Google Firebase and Facebook: ios-snapshot-test-case A "snapshot test case" takes a configured UIView or CALayer and uses the renderInContext: method to get an image snapshot of its contents. It compares this snapshot to a "reference image" stored in your source code repository and fails the test if the two images don't match. GitHub Facebook screenshot-tests-for-android Testing rendering for your Android app is hard. How do you prevent visual regressions in paddings and margins and colors from creeping in? Iterating on UI code is hard. How do you quickly verify that your layout or view changes work correctly in all configurations? screenshot-tests-for-android can solve these problems by providing a test framework that checks for visual differences across changes. GitHub Facebook Google Firebase Test Lab Test Lab l...