Waldemar Kornewald11/14/2023, 8:58 AM
APIs) ◦ … Either you develop the app for the client or they build it and integrate either your logic SDKs or ViewModels or your themable UI (or some combination). EDIT: For SDKs it’s important to have a simple way to expose the whole API, similar to the way it works on JVM with just public vs. private. The current JS/WASM export annotations are too painful and the XCFramework
build configs are also quite repetitive and error-prone when working with multiple SDKs and many modules. Let’s say there are 100+ modules overall. You need linting, Sonarqube, dependency update and security checks, snapshot and unit tests and code coverage, version consistency (e.g. BOM), API docs with real text and examples (not just Dokka-generated references, but more like Kotlin's docs), assets and translations (at
level, also overriding/customizing values from lower-level modules). Some consumers of your SDKs are allowed to see the source code, others only get the binaries - ideally with integrated API docs. Thus you’d want to keep the configuration as centralized as possible. Settings should ideally be transitive (e.g. iOS pods, webpack customizations, kotlinx.serialization, etc.). They should also be applied from the root and match on certain path patterns or module properties. With too much repetition you’ll lose yourself in complexity and will have a hard time updating configs and finding out how the build system is configured and which outputs there are at all (your different XCFrameworks, apps, etc.). Ideally you don’t have to look at 30 module.yaml files to understand which artifacts get built in the project. Side-problem: Your iOS apps with native UI need to integrate one or multiple XCFrameworks. Your iOS apps are modularized, too. So if foo-sdk and bar-sdk depend on common/oauth, the the iOS app’s modules need to reuse that common/oauth API and be able to pass objects to both foo-sdk and bar-sdk. That’s a huge problem because with the current build system SDKs become separate XCFrameworks/WASM/JS libs with their own incompatible copy (!) of common/oauth. So the resulting XCFrameworks/WASM/etc. need to be built and published in a modularized way somehow and this should ideally even work across multiple repos. I hope this is a useful example for discussing Amper’s solution. Is this even a use-case Amper wants to serve? Maybe a tiny similar project in the samples would be helpful, too (I think a lot of problems in the current Gradle based build system would’ve been avoided with such a more complex example).
Stylianos Gakis11/14/2023, 9:13 AM
Alexander Tsarev11/14/2023, 2:29 PM
Waldemar Kornewald11/15/2023, 5:29 PM