How To Retrofit my Existing App to Skip

[davidakoontz]

Let's go beyond the Hello World (Skippers) App... By what general process would I start moving my existing app into a ... skip framework?

Step 1: Do I start from a blank project in Xcode? OR - (my best guess) start from the Hello-Skip app with the structure and working code.

Step 2: What can I file-copy over to the new (renamed - yeah how?) Hello-Skip app that has other dependencies...? I guess at some point it requires everything be copied.

Step 3: So then I try to compile in Xcode... and it kicks in the SkipStone Transpiler... something is going to break... What's the general guidance for fixing / ignoring / redesigning...

Surely you have more advice to give along this topic...

What to do first...

What to do last or much later...

What is not (YET) going to work...

For example - SF Symbols... Colors... Fonts... etc.

Maybe you could explain the deeper meaning behind your Module meaning. e.g. "Skip is designed to accommodate and encourage using multi-module projects." I'm just a simple App builder... no modules required. What might I benefit from?

[marcprux]

The short answer is that Skip, at this early stage, is best suited to new, greenfield apps. That doesn't mean that you can't bring over your existing SwiftUI and business logic, it just means that you'll need to migrate it yourself.

We'll be writing a blog post and more documentation on this topic soon. In short, we envision the path from an existing iOS app to a dual-platform iOS/Android app using Skip will look something like this:

1. Create a new Skip project with skip init --appid=… project-name AppName ModuleA ModuleB ModuleC …. See https://skip.tools/docs/gettingstarted/
2. Take your existing app and move over the code, file by file, into the appropriate ModuleX module (for business logic) or the AppName module (for top-level SwiftUI code). Make sure the project builds and transpiles each time you make a change, either by running an Xcode Build or swift build in the project folder.
3. If your app has major dependencies on external non-Skipified frameworks, assess how best to replace or re-implement that functionality. Depending on the architecture of your app, this could be either a minor change (e.g., by using one of the standard Skip Frameworks from https://skip.tools/docs/modules/), or a major operation.
4. Write tests for each module and place them in Tests/ModuleATests/TestModuleA.swift tests. Run them with swift test or skip test to ensure that both the Swift and transpiled Kotlin tests pass. These tests will be exercising your logic in both the Swift and Kotlin (JVM) environments, which are quite different (see https://skip.tools/docs/developing/). Extensive testing is critical to the success of any Skip project.
5. Once all the modules are building and passing unit tests, move on to the user-interface code and start iterating on your app running it in tandem on the iOS Simulator and Android emulator. These environments are similar but not identical to their testing-environment counterparts (macOS for Swift and Robolectric for Kotlin), so you may need to make adjustments to your business logic.
6. Many SwiftUI features won't work until they are implemented. Visit https://github.com/skiptools/skip-ui/issues to see a list of open issue and how you can help. Missing SwiftUI features can be worked-around using #if SKIP blocks (see https://skip.tools/docs/platformcustomization/ for details).

Take it slowly and write lots of tests, and you'll be well on your way to to bringing your iOS app to Android and creating a genuinely native dual-platform application.

[davidakoontz]

Thank you Marc! That looks like a great start - I can do that!

…

On Nov 22, 2023, at 8:44 AM, marcprux ***@***.***> wrote: The short answer is that Skip, at this early stage, is best suited to new, greenfield apps. That doesn't mean that you can't bring over your existing SwiftUI and business logic, it just means that you'll need to migrate it yourself. We'll be writing a blog post and more documentation on this topic soon. In short, we envision the path from an existing iOS app to a dual-platform iOS/Android app using Skip will look something like this: Create a new Skip project with skip init --appid=… project-name AppName ModuleA ModuleB ModuleC …. See https://skip.tools/docs/gettingstarted/ Take your existing app and move over the code, file by file, into the appropriate ModuleX module (for business logic) or the AppName module (for top-level SwiftUI code). Make sure the project builds and transpiles each time you make a change, either by running an Xcode Build or swift build in the project folder. If your app has major dependencies on external non-Skipified frameworks, assess how best to replace or re-implement that functionality. Depending on the architecture of your app, this could be either a minor change (e.g., by using one of the standard Skip Frameworks from https://skip.tools/docs/modules/), or a major operation. Write tests for each module and place them in Tests/ModuleATests/TestModuleA.swift tests. Run them with swift test or skip test to ensure that both the Swift and transpiled Kotlin tests pass. These tests will be exercising your logic in both the Swift and Kotlin (JVM) environments, which are quite different (see https://skip.tools/docs/developing/). Extensive testing is critical to the success of any Skip project. Once all the modules are building and passing unit tests, move on to the user-interface code and start iterating on your app running it in tandem on the iOS Simulator and Android emulator. These environments are similar but not identical to their testing-environment counterparts (macOS for Swift and Robolectric for Kotlin), so you may need to make adjustments to your business logic. Many SwiftUI features won't work until they are implemented. Visit https://github.com/skiptools/skip-ui/issues to see a list of open issue and how you can help. Missing SwiftUI features can be worked-around using #if SKIP blocks (see https://skip.tools/docs/platformcustomization/ for details). Take it slowly and write lots of tests, and you'll be well on your way to to bringing your iOS app to Android and creating a genuinely native dual-platform application. — Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3SNUZSNF373NYZTRLFW5LYFYMUBAVCNFSM6AAAAAA7TZAS6WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMNBTHEYTG>. You are receiving this because you authored the thread.