3 ms·

The blog post reads like a high level overview and skips the real engineering behind the scenes. I wonder how they'll integrate native functionalities like geol

The blog post reads like a high level overview and skips the real engineering behind the scenes. I wonder how they'll integrate native functionalities like geolocation/audio-video/maps etc which are highly platform specefic.

georgyo 6y ago
They also said that less than 50% of the code was shared, which means there is still a lot of platform specific code. > Almost 50% of the production code in our Android and iOS apps is decoupled from the underlying platform.
- anupamchugh 6y ago
  With Apple, you can never expect them to expose platform specific APIs to other languages and frameworks outside their ecosystem.
gregkerzhner 6y ago
We are doing something similar on my project except using the J2OBJC compiler. The compiler is a cumbersome, unwieldy tool, but the cross platform approach overall is great. We write the core logic of our app using the cross platform approach. Platform specific APIs like geolocation or maps get handled natively, but pass their data off as inputs to the cross platform implementation. So for example, you wouldn't render a map natively, but you could write a handler for an updated location from a map, or query the network based on the current map area and return some results. An added bonus of this approach is that it forces you to have a clear separation between your user interface code, and your business logic. A lot of mobile (and front end) apps out there have no architecture, putting API calls, state management and UI right next to each other in the same modules. Our approach forces you to keep UI code just focused on UI, while keeping all logic somewhere else, where it can isolated and as a benefit much more easily unit tested. You would be surprised just how large of a share of your codebase can be moved into platform agnostic code if you have a solid architecture. Our UIs are "dumb" and render themselves from view models which have exactly the data needed to render the view. All the logic and state management to construct these view models can be written in the cross platform repo and shared across the Android and iOS apps. For example, to render a list, you will need to use the native UITableView or RecyclerView separately, but all the code that manages how many rows are in the list, the data each row needs, as well as updating the data when the list is reordered can be shared across platforms.
- rapsey 6y ago
  This approach is also great for testing. We use rust for parts of our mobile apps. If we were to do it again the rust part would be way larger.
  - Ryuuke 6y ago
    I've tried to use rust on mobile apps, but type conversion & manual memory management does make using it really hard and unappealing. Did you find a better way using rust that mitigate theses kinds of problems ?
    - rapsey 6y ago
      It all depends on your integration point and use case. The extra interopability work has to pay for itself. One possible trick is to use a message passing architecture and pass json/protobuf messages between the code bases. Some companies also use lots of ffi code generation tools.
someUserTonight 6y ago
You share as much code as you want in the shared/base project and are able to create "contracts" for each UI platform that are enforced by the compiler. If you're business logic needs these platform specific functionalities (which will definitely be the case as you've stated) then you can abstract out interfaces and let each platform handle them natively.

georgyo 6y ago

They also said that less than 50% of the code was shared, which means there is still a lot of platform specific code. > Almost 50% of the production code in our Android and iOS apps is decoupled from the underlying platform.

anupamchugh 6y ago
With Apple, you can never expect them to expose platform specific APIs to other languages and frameworks outside their ecosystem.

gregkerzhner 6y ago

We are doing something similar on my project except using the J2OBJC compiler. The compiler is a cumbersome, unwieldy tool, but the cross platform approach overall is great. We write the core logic of our app using the cross platform approach. Platform specific APIs like geolocation or maps get handled natively, but pass their data off as inputs to the cross platform implementation. So for example, you wouldn't render a map natively, but you could write a handler for an updated location from a map, or query the network based on the current map area and return some results. An added bonus of this approach is that it forces you to have a clear separation between your user interface code, and your business logic. A lot of mobile (and front end) apps out there have no architecture, putting API calls, state management and UI right next to each other in the same modules. Our approach forces you to keep UI code just focused on UI, while keeping all logic somewhere else, where it can isolated and as a benefit much more easily unit tested. You would be surprised just how large of a share of your codebase can be moved into platform agnostic code if you have a solid architecture. Our UIs are "dumb" and render themselves from view models which have exactly the data needed to render the view. All the logic and state management to construct these view models can be written in the cross platform repo and shared across the Android and iOS apps. For example, to render a list, you will need to use the native UITableView or RecyclerView separately, but all the code that manages how many rows are in the list, the data each row needs, as well as updating the data when the list is reordered can be shared across platforms.

rapsey 6y ago
This approach is also great for testing. We use rust for parts of our mobile apps. If we were to do it again the rust part would be way larger.
- Ryuuke 6y ago
  I've tried to use rust on mobile apps, but type conversion & manual memory management does make using it really hard and unappealing. Did you find a better way using rust that mitigate theses kinds of problems ?
  - rapsey 6y ago
    It all depends on your integration point and use case. The extra interopability work has to pay for itself. One possible trick is to use a message passing architecture and pass json/protobuf messages between the code bases. Some companies also use lots of ffi code generation tools.

someUserTonight 6y ago

You share as much code as you want in the shared/base project and are able to create "contracts" for each UI platform that are enforced by the compiler. If you're business logic needs these platform specific functionalities (which will definitely be the case as you've stated) then you can abstract out interfaces and let each platform handle them natively.