Cornelius Mark
Build it for one platform first and develop it for other platforms at a later time. This keeps expenses to verify low and improve it, before investing in another platform.
1 2
Tomáš Schmied
Exactly what we're doing. An iOS app (and elixir REST API) to show the product off to investors (we wanna have a live app before talking to anyone) and then we'll expand to Android and Web (probably Phoenix LiveView - bit of a gamble tbf, but worth it imo)
1 3
Corey Johnson
What made you decide on Swift Ui over other options? 😊 I haven't really touched it, but I have played around with Flutter and found it kinda nice (dart is kinda weird, though)
1
Tomáš Schmied
Flutter felt half-baked and after trying Swift UI and not coming across any hurdles, we just kept going with it. What was supposed to be an experimental build became the main branch.
1 2
GitSwifty
What versions are you supporting? Curious how many of my hurdles are due to needing to use the 3-year-old APIs 😬
1 1
Tomáš Schmied
We've looked at the iOS version market share for our target audience and the oldest version we're supporting right now is 15. Once we launch, we can backport some features and go for iOS 14 support, maybe even 13. Depends on the feedback we get.
1 1
Corey Johnson
I'm giving it a shot for my new app MVP but I'm having a hard time coming from kotlin and jetpack compose android 😞 The web to native mapping of styling, views, and life lifecycle stuff is quite challenging to wrap your head around at first
2 1
Samuel
yeah, it’s interesting coming at it as a native dev vs coming at it as a web dev. I came at it from web so very different experience probably
2
Fco Pardo
It does not really make sense to go from compose to react. Compose fixes stuff affecting react, and kotlin allows to truly separate declarative UI code from everything else. So it will feel weird. Maybe try adding a RN screen/component to a compose app...
2 1
Fco Pardo
... You can deal with the data in the same fashion you do now, have react read it from native, as a prop (stateless function parameter in compose). Then you can compare against a stateless compose version
1 1
Corey Johnson
That's a good tip! I definitely think this approach works better than some of the JS bridge workflows I've seen, at least if you don't need over the air updates
1
Corey Johnson
For what it's worth, I just wanted to see what building more than a hello world in RN would be like 😅 but I know there's tons of benefits sticking with kotlin! Figure it never hurts to broaden my perspective and appreciate what kotlin and compose offer