At Meero, we choose to develop our app to native way but we use the same architecture, same libraries and same naming of all crafted code.

1. Meero

2. Meero
• Create dedicated tools for photographers to make their life easier
• Prospecting
• Community
• No photo editing during production process

3. Objective Results
• Teach our algorithm the different
improvements performed by image
professionals
• Make it resistant to variations in
lighting (such as white balance ),
and image flaws (such as noise or
motion blur)

4. How we designed our iOS and
Android apps with same
architecture
And without cross-platform frameworks

5. Plan
• History
• State of cross-platform
• Considering developing iOS and Android apps in the same way
• Devsign thinking
• Future
• Conclusion

6. History
2007 2011 2014 2015 2016 2017 2018 2019
Android
iOS
Fragment RecyclerView
UIAlertViewController
Widget / Extension
UIStackView
SFSafariViewController
ForceTouch
Permissions
CustomsTabs
AppShortcuts
ConstraintLayout
Room
ARKit
Files
HomeIndicator
Notification provisionnal
Navigation arch
ARCore
HomeIndicator
SwiftUI
Combine
Geoloc permission
Darkmode
Compose
Flow
Geoloc permission
Darkmode

7. State of cross-platform

8. State of cross-platform
Mobile market development is still looking after the best cross-platform
solutions:
• PhoneGap/Cordova, Titanium, Appcelerator, SenchaTouch…
• ReactNative, NativeScript, RubyMotion, …
• Flutter, KotlinNative

9. State of cross-platform
Sharing
Business and UI logic code
Reducing
Time of development by
reducing the time to market
Ownership
Of the rendering engine
Updating
OTA with code push
Designing
Isomorphic application
Offering
Simple way to target
and develop for specific platform

10. State of cross-platform
Hard to choose
Because too many choices
Need to wait
Developers to give access to
the latest native SDK features
Reduce
Or equalize native performances.
Increase size of apps
Hidden cost
With additional bugs, limitations
new skills needed, technical stack
Are dropped
Titanium, Xamarin, Angular? (Ionic)
Subjected
To the rules of app stores for code push restrictions
Api violations (Electron) or webview shell

11. • Legacy projects
• Not started at the same time
• Started with different choices
• Beliefs and experiences of
developers.
iOS / Android apps Why ?
• Two different architectures
• Functional differences on same
features

12. Is it possible to write
cross-native apps in 2020 ?

13. Languages

14. • Optionnals
• Sealed class, data class
• Extensions, interface implementation, generics
• Immutabilité
• map - reduce - join - filter
• Delegated properties (by)
• Spannable string
• let?. / val ?: return
• …
• Optionnals
• Enums, structs
• Extensions , protocol extension, generics
• Immutabilité
• map - reduce- join - filter
• Property wrappers (@)
• Attributed string
• if let / guard let
• …

15. Swift code
Kotlin code

16. Appcode et Android Studio
😏

17. iOS et Android components

18. • Activity, Fragment, RecyclerView
• ConstraintLayout, LinearLayout, Compose
• Permission
• WorkManager
• Notifications (silent, local, push)
• DialogFragment / IntentChooser
• ARCore / Sceneform
• CustomTabs
• Room
• …
• ViewController, ChildViewController, UITableView
• Autolayout, UIStackView, SwiftUI
• Permissions
• Background Modes
• Notifications (silent, local, push)
• UIAlertViewController / UIActivityViewController
• ARKit / SceneKit
• SFSafariViewController
• CoreData
• …

19. ForgotPasswordViewController.swift ForgotPasswordActivity.kt

20. Librairies

21. • Share same apis
• Same behaviours
• Needs
• Maintenance, security, …
• Integration complexity
• Cost saving
• Licence
• …
Specific criteriaCommon criteria

22. • RxJava / RxAndroid
• Dagger2 / Koin
• Mockito - Spek - Atrium / AssertK
• Picasso / Glide / Coil
• Retrofit
• MPAndroidChart
• Realm
• …
• RxSwift
• Swinject
• Cuckoo - Quick - Nimble
• KingFisher / SDWebImage
• Alamofire router
• Charts
• Realm
• …

23. Mockito test code
Cuckoo test code

25. Architectures

26. Architectures
• MVC, MVP, MVVM, MVI
• Clean architecture
• Router / Coordinators
• Delegation
• Decorators

28. • Modifications must be done twice
• Rigorous respect of naming
conventions, folder tree, …
• Complicated to be 100%
• Synchronous update to avoid
divergences
Pros Cons
• Common reflexion
• Fatest bugs detection, same bugs
• Seamless switch from iOS to
Android, quick learning curve
• Same functional behaviours
• No architecture debate during
reviews between platform

29. Tooling

30. • Ktlint, AndroidLint
• Ktlint (--format)
• Bitrise, Fastlane, Danger, …
• SwiftLint
• SwiftFormat
• Bitrise, Fastlane, Danger, …

31. Team

32. Team
• At least one Team Lead
• Guardian of the rules and process
• Experience on both platform
• Developers
• Knowledge at least on one platform
• Motivated to learn developing / reviewing the other platform
• Open minded
• Curious

33. • New constraints for work
• Must hire people that can embrace
this vision of cross-native
development
• Communication is mandatory
Pros Cons
• Share ownership of the apps
• Share technic knowledges
• Co-construction
• Create communication
• A “single” team
• Natural for feature team

34. How to succeed ?

35. Devsign thinking

36. Devsign thinking
• Design thinking for developers
• Development cycle in three steps
Reflexion
DevelopmentCross reviews

37. First step - reflexion
• Discussing and picking about the best solution for design the new
feature in the same way on both platform
• During grooming and / or specific technical meeting
• At least one iOS and Android developer

38. Second step - development
• Keys to achieve:
• Respect the technical choices and decisions
• Communication for problems or enhancement

39. Step three - cross reviews
• iOS code should be reviewed by Android developer for the same feature
• Should be reviewed by third person to improve or definitely validate
• Cross testing
• Communication !
• No compromise without validation from both parties

40. Conclusion

41. • Some step could be complicated to
perform on big legacy project
• Communication
• Technical debates could be long
• Bigger is the feature, longer will be
the review
Benefits Obstacles
• Easy to perform for a new project
• Force conventions
• Opportunity for refactoring legacy
portion of code
• Opportunity for develop on other
platform
• Makes you more valuable, new career
opportunities

42. Once you tried it,
you can’t go

43. Future
• Use Danger to automatically check naming function, files and folders trees
• Continue with web front-development for same features (react native
strength)
• Prepare the field if tomorrow we really have to deal with ReactNative,
Flutter or KotlinNative.

44. Thank you
+ = ❤

45. Christopher SAEZ
Mobile developer @meero
christopher.saez@meero.com
https://www.linkedin.com/in/saezchristopher/