swift-evolution VS GmsCore

According to their changelog[0], Clock was added to the standard library with Swift 5.7, which shipped in 2022, at the same time as iOS 16. It looks like static linking by default was approved[1] but development stalled[2].

I expect that it's as simple as that: It's supported on iOS 16+ because it's dynamically linked by default, against a system-wide version of the standard library. You can probably try to statically link newer versions on old OS versions, or maybe ship a newer version of the standard library and dynamically link against that, but I have no idea how well those paths are supported.

0. https://github.com/apple/swift/blob/main/CHANGELOG.md

1. https://github.com/apple/swift-evolution/blob/main/proposals...

2. https://github.com/apple/swift-package-manager/pull/3905

[A Vision for Embedded Swift](https://github.com/apple/swift-evolution/blob/main/visions/e...) has the details on this new build mode and is quite interesting.

> Effectively, there will be two bottom layers of Swift, and the lower one, “non-allocating” Embedded Swift, will necessarily be a more restricted compilation mode (e.g. classes will be disallowed as they fundamentally require heap allocations) and likely to be used only in very specialized use cases. “Allocating” Embedded Swift should allow classes and other language facilities that rely on the heap (e.g. indirect enums).

Also, this seems to maybe hint at the Swift runtime eventually being reimplemented in non-allocating Embedded Swift rather than the C++ (?) that it uses now:

> The Swift runtime APIs will be provided as an implementation that’s optimized for small codesize and will be available as a static library in the toolchain for common CPU architectures. Interestingly, it’s possible to write that implementation in “non-allocating” Baremetal Swift.

I may be out of my depth here as I've only casually used Rust, but this seems similar to Swift's proposed lifetime dependencies[1]. They're not in the type system formally so maybe they're closer to poloneius work

[1]: https://github.com/apple/swift-evolution/blob/3055becc53a3c3...

Swift recently adopted a region-based approach for safe concurrency that builds on Milano et al’s ideas: https://github.com/apple/swift-evolution/blob/main/proposals...

No, it's not. Refcounting CAN be a garbage collection algorithm, but in Swift it's deterministic and done at compile time. Not to mention recently added support for non-copyable types that enforces unique ownership: https://github.com/apple/swift-evolution/blob/main/proposals...

You can stackallocate buffers with unsafe Swift but it's not exactly fun to use. https://github.com/apple/swift-evolution/blob/main/proposals/0322-temporary-buffers.md

I, an engineer, am not doing this myself, too. There is a middle ground though: just use a privacy-oriented Android build, like DivestOS. [1]

There are a couple caveats:

1. It is still a bit tricky for a non-technical person to install. Should not be a problem if they know somebody who can help, though. There's been some progress making the process more user friendly recently (e.g. WebUSB-based GrapheneOS installer).

2. There are some papercuts if you don't install Google services on your phone. microG [2] helps with most but some still remain. My main concern with this setup is that I can't use Google Pay this way, but having to bring my card with me every time seems like an acceptable trade off to me.

[1]: https://divestos.org/

[2]: https://microg.org/

I have been running de-googled LineageOS since before it renamed/reformed from CyanogenMod, so since somewhere around 2013/14. That has looked rather different depending on what exactly I need from my phone but I'll share what my current set up looks like.

First, I have don't use any kind of Google/Samsung/Apple Pay wallets so if you do, this may not be helpful; I've never looked into trying to get any of those working. Also, by "de-googled" I mean that I don't have GApps installed on my phone. I do have microG[0] installed as a Magisk[1]/LSPosed[2] module; this allows a few apps to believe I have GApps while most apps do not see/have access. I do not turn on microG for any apps (i.e. no connection to the Google servers/services via microG).

Most of my apps come from F-Droid[3], a few from Aurora Store[4] (a 3rd-part frontend for the Play Store that does not require either an account or GApps installed), a very few from FFupdater[5], and have played with using Obtanium[6] but currently only have one (weather) app updating via it. I have several different repositories configured in F-Droid but I don't generally keep mental track of which repository I am dependent on for which apps; the default, IzzyOnDroid[7], Bitwarden[8], NewPipe[9], microG[10], and Collabora[11] are some of them.

I have two banking apps installed via Aurora Store, one of which requires microG and root-hiding (via Magisk module) while the other doesn't require either. My browsers (Firefox, Firefox Klar, Brave) come from FFupdater and none require microG. My texting (QUIK SMS), email (K-9 Mail), TOTP authenticator (Aegis), password manager (Bitwarden), GPS/Maps (OsmAnd), file syncing (Nextcloud), notes (Nextcloud Notes), HN reader (HN), and Contacts/Calendar sync (DAVx5, ICSx5) apps all come via F-Droid (either the main repo or others). I have many others apps which come from F-Droid or Aurora Store but the above are my most used.

For file, calendar, notes, photo, & contact syncing, I have a Nextcloud server set up and find it to work quite well; the Nextcloud apps are also quite good. Someone who doesn't want to run their own could use a hosted account[12]. Contacts & calendars are synced to Nextcloud via DAVx5 & ICSx5.

The primary challenges I am aware of at this point are hardware (it is increasingly difficult to install LineageOS on most hardware due to bootloader locks), and navigation (OpenStreetMap data usually doesn't include addresses in the USA). For hardware, the solution is essentially just to properly research the phone you want to buy; I always make sure the model is well supported by LineageOS before purchasing and then tend to hang on to it for several years. For navigation, I usually find the address on my desktop or mobile browser (via DuckDuckGo) and then manually input the location into OsmAnd before the trip but I also keep WeGo Here maps installed in case I don't have time for that (it usually takes <2 minutes and rarely more than 5 to manually find & enter the address). Additionally, getting the one banking app to work without GApps was a pain in the butt initially (requiring testing several Magisk & LSPosed modules), but now it just works and I don't really think about it.

Overall, I don't find my version of de-googled to be a detriment; my phone is useful and I have more control over my data and over annoyances (such as unnecessary notifications) than I would otherwise.

[0] https://microg.org

Is anyone here daily-driving microg and can share their experiences? https://github.com/microg/GmsCore/wiki/Implementation-Status does not exactly inspire confidence.

...will need to be rewritten to avoid Google Play Services.

Not true.

All that needs to happen is for open source developers to "re-implement Google’s proprietary Android user space apps and libraries".

https://microg.org/

microG itself connects directly to Google: https://github.com/microg/GmsCore/wiki/Google-Network-Connec...

No shit, of course they do.

>In general, we obviously try to minimize the connections to Google, but some services strictly rely on them and would just not work without.

What exactly do you think they should do instead?

MicroG

In release notes for GmsCore v0.2.29.233013 (https://github.com/microg/GmsCore/releases/tag/v0.2.29.233013), I also see:

Yes, the Xposed module is one way. There are also other ways

Which one should I use? Is this MicroG's official website right? (https://microg.org/)