Intent gave us code for microPebble running on iOS. I should build it and try it out, but we should also figure out what we want to do with it in general.
Things to figure out:
What about the libpebble3 world? If Core is going to have a merged repo for the foreseeable future, should we have a libpebble3 fork of our own that we cherry pick their changes into that doesn’t force a CoreApp build?
We need to figure out the iOS changes and understand what and why they made changes.
We should look at the quality of their code and see if it looks good enough to continue with them.
We should figure out how to upstream their changes.
Where will microPebble live? pebble-dev/microPebble? still as a matejdro repository? as pebble-dev/cobble? a different name entirely?
@matejdro specifically, but everyone invited to discuss
In short term, I think having a fork of libpebble3 is mandatory, because Core’s repo includes a whole app - you would have to download the entire Core app and include it in the project just to get the libpebble3 out. Having a fork with the Core app removed (or at least disabled so it doesn’t clutter up the build process) seems more sane.
I’m wondering what are the longer term plans here? Is the plan to create microPebble iOS first and then transition into converting the app into Cobble design?
I think this is kind of my thought – though depends on what they have to say about the Flutter / libpebble3 situation.
As I understand it, they basically already have microPebble iOS. Then it would be good to do some basic skinning of it, and then itemize what we’re missing to get all the features we wanted from Cobble and implement them.
If needed I can also help build, review, and document the processes for the iOS part of the app that they delivered. Personally I don’t have that much experience with KMP or CMP but I do have lots with iOS dev and Swift.
OK I got it to build! And it paired with my snowy! And then it wiped all my watchfaces and watchapps since it doesn’t know how to sync with my locker yet. But it does work.
I went through the code and commits and it looks really promising, the code is clean and maintainable. I still wrote down some minor notes:
Their approach of migrating business logic to repositories and presents are good design patterns to share as much logic as possible.
Some of their comments are a bit needed, for example fun stopBleScan() has the comment Stops active BLE scan. IMO function names should be self documenting and comments should only be added to document special conditions or edge cases or when it’s not possible to make the name self documenting. But I know that in open source projects rules like documenting as much as possible might be a good idea.
Enabling NSAppTransportSecurity NSAllowsArbitraryLoads is not recommended and I believe is not allowed by apple (boot.rebble.io, this should be available with ssl? Right)
They tested using native iOS UI through SwiftUI which is very fast to write, that also looked simple, and would bring the benefit of native interactions and performance (although CMP performance is pretty good). In that part I did have some observations that can be taken with a grain of salt as that was just a phase of the POC and not what was actually delivered:
Detached tasks are being created that are not being destroyed, this could lead to memory leaks WatchListView.
Ideally you would add a mechanism to cancel this task when the view is no longer presented.
If we wanted to go through the native UI route I would recommend implementing design constants such as colors, spacings, and fonts.
We would want to transform all Kotlin Flows into asynchronous sequences like in the example above instead of using completion handlers to observe results (I saw both approaches). The current preferred architecture for swift apps is Swift Concurrency (async/await, async sequences) and not Combine or completion handlers.
I’m not sure what was the min target set for them but on iOS 17+ native code I would recommend using Apple’s Observation framework instead of ObservableObject
New extra note:
Not really a note about their work but more about CMP, the dev-team still needs to manually migrate each view into the shared target and make changes for it to work properly on both platforms, I believe that’s why there’s views and UI missing from iOS
It is also disabled on the Android side, due to PBJS config pages - some are hosted on the http links and lots of them are not updated anymore, so you can’t enforce HTTPS only withour breaking them. They are also arbitrary URLs, so you can’t really set up an exclusion list in compile time
