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

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
2 comments
Read more

FF Chartwell: Defining pie chart, bar charts and many others via vector font!

  With FF Chartwell you can define Charts via OpenType font, and transform a string, e.g. " 60+ 30 + 10 " into a Pie Chart 60%-30%-10% including color support (not only b/w!) without rendering anything: directly via font without using any images! Check this out: FontBlog FF Chartwell So great!
Post a Comment
Read more

Writing High-Performance Swift Code

Enabling Optimizations Whole Module Optimizations (WMO) Reducing Dynamic Dispatch Dynamic Dispatch Advice: Use 'final' when you know the declaration does not need to be overridden Advice: Use 'private' and 'fileprivate' when declaration does not need to be accessed outside of file Advice: If WMO is enabled, use 'internal' when a declaration does not need to be accessed outside of module Using Container Types Efficiently Advice: Use value types in Array Advice: Use ContiguousArray with reference types when NSArray bridging is unnecessary Advice: Use inplace mutation instead of object-reassignment Wrapping operations Advice: Use wrapping integer arithmetic when you can prove that overflow cannot occur Generics Advice: Put generic declarations in the same module where they are used The cost of large Swift values Advice: Use copy-on-write semantics for large values Unsafe code Advice: Use unmanaged references to avoid reference counting overhead Protocols Ad...
Post a Comment
Read more

Lean prioritization matrix

  We are sorting the stream of stakeholder request and product ideas in a KPI-weighted table. The Matrix This 2x2 matrix low effort vs. high effort high value vs. low value is a nice and easy consumable visualization model. The Weights Suggested weights are Reach How many customers does the feature impact? Customers New/existing target groups Revenue Will it drive revenue either direct or via extended CLV? Acquisition Will the feature help drive new customers? Efficiency Does the feature help drive efficiency in customers’ lives – be that internal customers (colleagues), or external (paying) customers? Brand Does the feature enhance your brand awareness? The classification/quadrants Top left to bottom right Q1 Do it now! Q2 Break it down and put in prio sequence Q3 Gap filler Q4 Forget about it... for now. Andy Wicks - Mind the product
Post a Comment
Read more

iOS In-App Browser JavaScript injections to spy on user behaviour on 3rd party websites

 iOS Privacy: Instagram and Facebook can track anything you do on any website in their in-app browser The iOS Instagram and Facebook app render all third party links and ads within their app using a custom in-app browser. This causes various risks for the user, with the host app being able to track every single interaction with external websites, from all form inputs like passwords and addresses, to every single tap. KrauseFX
Post a Comment
Read more

Apple Sneaks A Big Change Into iOS 5: Phasing Out Developer Access To The UDID

Apple is making a lot of big changes to its mobile operating system with iOS 5, which is dribbling out in betas for developers ahead of a general release later this year. But there is one big change some developers are just starting to take notice of that Apple isn’t talking about that much. In a recent update to the documentation for iOS 5 (which is only available to registered Apple developers, but a copy was forwarded to me), Apple notes that it will be phasing out access to the unique device identifier, or UDID, on iOS devices such as iPhones and iPads. TechCrunch Solution A: UIDevice-with-UniqueIdentifier-for-iOS-5 Brings back the unique identifier support under iOS 5, it uses the device's mac address in combination with the bundle identifier to generate a new hashed unique identifier. gekitz GitHub Alternate Solution B: Appsfire Announces Open Source UDID Replacement For iOS: OpenUDID It is based on the NSProcessInfo (see globallyUniqueString), but may change ...
Post a Comment
Read more

Starting UIAutomation via command line

You can do it now, starting with XCode 4.2 for iOS5 beta 4 From command line, you can run instruments pointing to the automation template and specify as environment variables the test script you want to execute and destination path for results: instruments -w device_id -t /Developer/Platforms/iPhoneOS.platform/Developer/Library/Instruments/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate application -e UIASCRIPT script -e UIARESULTSPATH results path DevForums Apple instruments Mac OS X Developer Tools Manual Page
Post a Comment
Read more