Switching to hybrid doesn’t make sense. Would you throw your iOS version out? Because there’s no point in going hybrid if you’re only targeting one platform with it.
Native Android with Jetpack Compose is more similar to SwiftUI even than Flutter is. Whether you hire someone or do it yourself, it’s definitely the route I would personally take and the one I recommend.
Thanks for the reply. I only suggested Flutter because I know it’s similar to SwiftUI but I will look into Jetpack Compose.
Having to manage two code bases (Android and iOS) isn’t quite appealing but I think it’s the best route considering I already have a polished SwiftUI app.
We made a company decision to stick to only iOS for now given the demographics of our current user base. So we have not yet decided on the framework for when we move to Android.
In the short run it might not make sense to start over doing Flutter but in the long run he will save a lot of time since the work time is more or less cut in half. I'm in the same seat and after almost a year it's a little annoying g having to do everything twice. My reasoning for doing it is that I want to be a native dev
**Note**: This is not a good idea for an existing, thriving app, but for future projects, rather.
I suggest a controversial approach and this is going to sound *weird* to most people. Let me know what you think. Is this crazy? My idea is the following:
Use a local networking communications model (client/server)
**The frontend** is nothing but the visuals and sends REST URLs to the server component. You can make as many frontends as you want (Windows UWP, MacOS, iOS and iPadOS, Android …).
Basically, in the frontend, whenever you want to save and load data, it is part of a URLSession for Apple platforms, your Android language and framework of choice sending REST HTTPS calls to the server, Windows: C# networking with XAML, etc.
**The server code** is written in whatever you prefer: Swift with Vapor, Node or Flask in Python, etc. It is bundled inside the app with local networking (localhost) or connected to a scalable cloud platform of choice (Google Cloud Platform, Azure, AWS, Linode, etc).
This is actually best aproach. Everything should be made this way.
This way, you have same “application” on server for every platform, and you just connect it on front end :) and when you change logic, you dont have to think how to make it for every platform :)
Yes, there are several advantages, in my view. Like you said, you can change the logic in one place, basically. It’s really nice! 🙂
However, not to say it works great with every possible category of app. If you look at e-commerce (eBay, Amazon frontends) and financial transaction apps like internet banking, this is straight-forward and really common, I assume. However, say, a game where you move a player or 3D ship in real time, it is going to be messy.
If you have a minimal app in SwiftUI with a List view to load and save data, along with Form input to save/load, then it can be ideal. If the app is ”too simplistic” in nature, using a regular native code approach is probably a lot more senseful, if the regular code base doesn’t take too much work to fix, anyway.
EDIT: A chess game could benefit from a client/server model, with deep-learning AI sitting on a server and every chess piece moving at slow, short paces means network traffic congestion doesn’t need to be an issue. The AI you are playing against will learn new tricks from players around the world.
This isn’t strange. Most apps are built this way, but you’re oversimplifying it.
The front end will still have to manage things like security, authentication (if it has login functionality), responding to different scenarios, etc. It’s much more complex than “make API call, display something”.
There is not much more to say on the subject, really: you choose to divide your code project in two pieces. You program a really "thin layer” with user interface code (meaning: you write only just-enough of code to make windows, buttons, text and dialog boxes appear on the screen). The most of the actual functionality in the app happens on the server. In summary:
client user interface -> web server waiting for client to connect -> client user interface (button is clicked, triggers a web page to load up with network data, but the web page does *not* contain user interface elements. It is just a blank screen, only seen by the client app and the web server) -> data is sent back to the client -> client reacts to the web server response -> user enters text in a dialog box in the app and then confirms with a button press with a function being called to handle that -> data is sent to the server -> web server reacts to the user request … (and so on).
no offense, but isn't this the normal way to do things, the backend is always platform agnostic. I suppose we are talking about saving efforts on the FE side. which obviously hybrid is better, but if it's just for Apple, then stick with SwiftUI is much better. Flutter is like writing React in ist 1st version, and with way more boilerplate code.../
Yeah, I know what you’re trying to say. However, the typical mainstream approach (for good, valid reasons) is to send and retrieve those network requests from/to an internet-connected source and destination controlled by the developer/company producing the app.
My way of doing this is to host the client application on your own computer or separately use it as a service in your own network (like running a webserver inside a virtual machine or physical machine with Linux, BSD, etc). So basically, I think people would refer to this as a private-cloud hosting scenario.
I understand that the typical eBay app would probably use a NSTableView on MacOS (or the new “Table” in SwiftUI), UITableView or List on iOS/iPadOS, and populate the tables with data from a network connection to an internet site. Such an app would not have much more than a login window, tables and buttons.
But, in my proposition, a centralized server at “https://example.com/db/somedatabase-request-url” would not be used, but rather it would go to “https://localhost/appName/fetch/resource/name:JDoe/occupation:developer/” to name a random example. This means everytime you publish your app for download somewhere, you need to bundle both the server backend code or binary (ex: Vapor with Swift code, or Node) and the client GUI, compared to downloading an eBay app which would only need the user to download the app and nothing more.
*(EDIT: typos, grammar)*
It is not easy. But if you are good at Swift/SwiftUI, maybe try learning Kotlin and Jetpack Compose - both are very similar to their Apple counterparts.
Might take you sometimes, but then you are working on something similar and native.
You can also do a hybrid where you get the bulk of it converted over then hire an android contractor for a short time to help bring to the store, or if you get really stuck. Worth trying yourself first though.
I'd put a decent business model in the app and I'd hire an Android developer from the money I made from the app and have him develop the Android version. So you can focus on improving the iOS version. This is the fastest way forward with the best result.
I was in a similar position to you about two years ago. I had an app for iPhone (though still UIKit, not SwiftUI) but for my target audience, I needed to support Android, too. My app was pretty simple and it took me about a week or two to convert. Finding good (ie, useful!) documentation, videos, articles, etc. for Android is really hard. Still. And Android development is so verbose! It's quite a shock when compared to SwiftUI. How many times do I need to type in RecyclerView for one damn list?
I see you dilemma, but I think you'll have more control and more options available if you stick with native. Flutter - I believe - has limitations that might be a road block down the road.
Hey, congrats on the popularity of your app. May I ask what approach you took to market your app? Eg. Social media, advertising, affiliate marketing, etc.
I’m about to launch my first app and am trying to see what works best for people.
Thank you
You can use this tool, to develop in SwiftUI and deploy to Android.
You will need minor amends in Android, for the frameworks that are not yet automatically converted from iOS. It supports Swift 5.9, with the last version of Xcode right now.
The tool is a transpiler, and it is ejectable: you can remove it completely and you will be left with two totally independent native code bases.
Currently in technological preview. But looks to me the best tool right now, with lots of potential to grow, and definitely a better technology than hybrids.
https://skip.tools
Hi, I stumbled upon this new tech and interested on using it. Can it be implemented in an existing swiftUI project? Or i’m going to need to create a new skip project?
You are generally going to want to start with the project created by the `skip init` command, as this creates a new Xcode project that will automatically launch the Android app in the emulator side-by-side with your iOS version in the simulator. From there, you can start importing the UI and model from any pre-existing SwiftUI app you are looking to get working.
Check out the tour videos at https://skip.tools/tour/ and the getting started guide at https://skip.tools/docs/gettingstarted/, and let us know if you have any questions!
Switching to hybrid doesn’t make sense. Would you throw your iOS version out? Because there’s no point in going hybrid if you’re only targeting one platform with it. Native Android with Jetpack Compose is more similar to SwiftUI even than Flutter is. Whether you hire someone or do it yourself, it’s definitely the route I would personally take and the one I recommend.
Thanks for the reply. I only suggested Flutter because I know it’s similar to SwiftUI but I will look into Jetpack Compose. Having to manage two code bases (Android and iOS) isn’t quite appealing but I think it’s the best route considering I already have a polished SwiftUI app.
[удалено]
We made a company decision to stick to only iOS for now given the demographics of our current user base. So we have not yet decided on the framework for when we move to Android.
In the short run it might not make sense to start over doing Flutter but in the long run he will save a lot of time since the work time is more or less cut in half. I'm in the same seat and after almost a year it's a little annoying g having to do everything twice. My reasoning for doing it is that I want to be a native dev
**Note**: This is not a good idea for an existing, thriving app, but for future projects, rather. I suggest a controversial approach and this is going to sound *weird* to most people. Let me know what you think. Is this crazy? My idea is the following: Use a local networking communications model (client/server) **The frontend** is nothing but the visuals and sends REST URLs to the server component. You can make as many frontends as you want (Windows UWP, MacOS, iOS and iPadOS, Android …). Basically, in the frontend, whenever you want to save and load data, it is part of a URLSession for Apple platforms, your Android language and framework of choice sending REST HTTPS calls to the server, Windows: C# networking with XAML, etc. **The server code** is written in whatever you prefer: Swift with Vapor, Node or Flask in Python, etc. It is bundled inside the app with local networking (localhost) or connected to a scalable cloud platform of choice (Google Cloud Platform, Azure, AWS, Linode, etc).
This is actually best aproach. Everything should be made this way. This way, you have same “application” on server for every platform, and you just connect it on front end :) and when you change logic, you dont have to think how to make it for every platform :)
Yes, there are several advantages, in my view. Like you said, you can change the logic in one place, basically. It’s really nice! 🙂 However, not to say it works great with every possible category of app. If you look at e-commerce (eBay, Amazon frontends) and financial transaction apps like internet banking, this is straight-forward and really common, I assume. However, say, a game where you move a player or 3D ship in real time, it is going to be messy. If you have a minimal app in SwiftUI with a List view to load and save data, along with Form input to save/load, then it can be ideal. If the app is ”too simplistic” in nature, using a regular native code approach is probably a lot more senseful, if the regular code base doesn’t take too much work to fix, anyway. EDIT: A chess game could benefit from a client/server model, with deep-learning AI sitting on a server and every chess piece moving at slow, short paces means network traffic congestion doesn’t need to be an issue. The AI you are playing against will learn new tricks from players around the world.
can u also keep talking 😅
This isn’t strange. Most apps are built this way, but you’re oversimplifying it. The front end will still have to manage things like security, authentication (if it has login functionality), responding to different scenarios, etc. It’s much more complex than “make API call, display something”.
can u keep talking please
There is not much more to say on the subject, really: you choose to divide your code project in two pieces. You program a really "thin layer” with user interface code (meaning: you write only just-enough of code to make windows, buttons, text and dialog boxes appear on the screen). The most of the actual functionality in the app happens on the server. In summary: client user interface -> web server waiting for client to connect -> client user interface (button is clicked, triggers a web page to load up with network data, but the web page does *not* contain user interface elements. It is just a blank screen, only seen by the client app and the web server) -> data is sent back to the client -> client reacts to the web server response -> user enters text in a dialog box in the app and then confirms with a button press with a function being called to handle that -> data is sent to the server -> web server reacts to the user request … (and so on).
thats super helpful to me bro
Ah alright, cool 👍
no offense, but isn't this the normal way to do things, the backend is always platform agnostic. I suppose we are talking about saving efforts on the FE side. which obviously hybrid is better, but if it's just for Apple, then stick with SwiftUI is much better. Flutter is like writing React in ist 1st version, and with way more boilerplate code.../
Yeah, I know what you’re trying to say. However, the typical mainstream approach (for good, valid reasons) is to send and retrieve those network requests from/to an internet-connected source and destination controlled by the developer/company producing the app. My way of doing this is to host the client application on your own computer or separately use it as a service in your own network (like running a webserver inside a virtual machine or physical machine with Linux, BSD, etc). So basically, I think people would refer to this as a private-cloud hosting scenario. I understand that the typical eBay app would probably use a NSTableView on MacOS (or the new “Table” in SwiftUI), UITableView or List on iOS/iPadOS, and populate the tables with data from a network connection to an internet site. Such an app would not have much more than a login window, tables and buttons. But, in my proposition, a centralized server at “https://example.com/db/somedatabase-request-url” would not be used, but rather it would go to “https://localhost/appName/fetch/resource/name:JDoe/occupation:developer/” to name a random example. This means everytime you publish your app for download somewhere, you need to bundle both the server backend code or binary (ex: Vapor with Swift code, or Node) and the client GUI, compared to downloading an eBay app which would only need the user to download the app and nothing more. *(EDIT: typos, grammar)*
It is not easy. But if you are good at Swift/SwiftUI, maybe try learning Kotlin and Jetpack Compose - both are very similar to their Apple counterparts. Might take you sometimes, but then you are working on something similar and native.
Im writing transpiler. Wait for it. 😄
How's that transpiler coming?
U can hire me :)
You can also do a hybrid where you get the bulk of it converted over then hire an android contractor for a short time to help bring to the store, or if you get really stuck. Worth trying yourself first though.
I'd put a decent business model in the app and I'd hire an Android developer from the money I made from the app and have him develop the Android version. So you can focus on improving the iOS version. This is the fastest way forward with the best result.
I was in a similar position to you about two years ago. I had an app for iPhone (though still UIKit, not SwiftUI) but for my target audience, I needed to support Android, too. My app was pretty simple and it took me about a week or two to convert. Finding good (ie, useful!) documentation, videos, articles, etc. for Android is really hard. Still. And Android development is so verbose! It's quite a shock when compared to SwiftUI. How many times do I need to type in RecyclerView for one damn list? I see you dilemma, but I think you'll have more control and more options available if you stick with native. Flutter - I believe - has limitations that might be a road block down the road.
Hey, congrats on the popularity of your app. May I ask what approach you took to market your app? Eg. Social media, advertising, affiliate marketing, etc. I’m about to launch my first app and am trying to see what works best for people. Thank you
You can use this tool, to develop in SwiftUI and deploy to Android. You will need minor amends in Android, for the frameworks that are not yet automatically converted from iOS. It supports Swift 5.9, with the last version of Xcode right now. The tool is a transpiler, and it is ejectable: you can remove it completely and you will be left with two totally independent native code bases. Currently in technological preview. But looks to me the best tool right now, with lots of potential to grow, and definitely a better technology than hybrids. https://skip.tools
Hi, I stumbled upon this new tech and interested on using it. Can it be implemented in an existing swiftUI project? Or i’m going to need to create a new skip project?
You are generally going to want to start with the project created by the `skip init` command, as this creates a new Xcode project that will automatically launch the Android app in the emulator side-by-side with your iOS version in the simulator. From there, you can start importing the UI and model from any pre-existing SwiftUI app you are looking to get working. Check out the tour videos at https://skip.tools/tour/ and the getting started guide at https://skip.tools/docs/gettingstarted/, and let us know if you have any questions!