Featbit OpenFeature Providers for Mobile

[lopezm1]

Hello! Do you have any plans to support mobile native Featbit SDKs?

I noticed Feabit does not have support for iOS (swift) or Android (kotlin / java).

If there are no plans, we were wondering if you had a list of requirements or considerations we should keep in mind when developing our own.

@cosmic-flood

[cosmic-flood]

Hi @lopezm1 One of our customers has contributed native SDKs for both iOS and Android:

https://github.com/featbit/featbit-ios-sdk
https://github.com/featbit/featbit-android-sdk

I reckon they are already using these SDKs in some of their apps. Please feel free to take a look—they may also serve as useful references if you decide to develop your own SDKs.

If they fit your needs, it would be even better if we could collaborate on the same projects rather than maintain separate implementations. If you try them and have any feedback or suggestions, we’d be happy to work together on further improvements.

[lopezm1]

Incredible. I missed these. Thank you!

We are more than happy to contribute and maintain a common implementation with you. We will review these and open issues as needed.

Thank you @cosmic-flood

[lopezm1]

@cosmic-flood --- I sent these SDKs to mobile team but we realized these are not OpenFeature Providers.

Do you have any plans for OpenFeature providers for mobile or golang?

https://github.com/featbit?q=openfeature&type=all&language=&sort=

We would be happy to help contribute if there are none yet. Golang, Swift and Kotlin.

[deleteLater]

The OpenFeature SDK is simply a lightweight wrapper around the original SDK. Therefore, if the original SDK is well-implemented, this is a relatively straightforward task.

We welcome contributions to openfeature-provider. If you have any questions, feel free to contact us.

[lopezm1]

We are happy to produce them for general availability. Could you help me create repositories we can make a PR into and you can help us review? @deleteLater

[lopezm1]

Update: we no longer need golang. Java server should be enough for us.

[deleteLater]

We recently wrote specifications for the Client SDK and Server SDK. We haven't covered the Mobile SDK yet; the Mobile SDK will generally follow the Client SDK's design, but it will incorporate some features specific to mobile platforms, such as

1. Need handle frequent offline states
2. Requires robust, encrypted on-device disk storage so flags are immediately available upon app launch—even offline.
3. Tied to mobile operating system events (e.g., app entering background, waking up, or battery saving modes).

etc.

[lopezm1]

We had some feedback from the mobile team. We will follow up soon with a list of questions we had. Thank you @deleteLater

[lopezm1]

@cosmic-flood + @deleteLater

Here are the list of concerns compiled by my Mobile team.

### General

* Both SDKs store flags **in memory only**. The SDKs expose `allFlags()` and `bootstrap(...)`, so the application is responsible for persisting and restoring flag state across launches.
* Both SDK stores support `get`, `getAll`, and `upsert`, but **do not expose delete/remove or replace-all behavior**.
* The polling implementations iterate over returned flags and call `upsert`. If a flag disappears from the server response, there is no corresponding removal from the local store, so stale flags can remain unless the application handles this separately.
* These are not longstanding native FeatBit SDKs. Both repos state they were created because FeatBit did not previously provide native Swift/Kotlin SDKs and are based on Fluent Health implementations.

### iOS

* There is currently **no GitHub release** for the iOS SDK.
* The parent repo has an open release issue stating that `0.1.0` still needs to be tagged and that the README's `from: "0.1.0"` dependency does not currently resolve.
* A large refactor/hardening PR is still open and in draft. It includes concurrency fixes, endpoint validation, lifecycle changes, store changes, and additional tests.
* That PR explicitly says **iOS simulator and physical-device testing are still outstanding**.
* The SDK previously had a streaming bug where using the Android-derived URL handling caused `URLSessionWebSocketTask` to throw and **crash the host app when streaming started**. That was fixed in June.
* The FeatBit repo is a fork of the Fluent Health repo. Their current `main` branches are aligned, but the newer hardening/refactor work is still only in the parent PR.

### Android

* Android has a published **v0.1.1** release.
* Android has the same **in-memory-only persistence model** and the same lack of delete/remove support in the flag store.
* The Android polling path also only calls `upsert` for returned flags, so the stale/deleted-flag concern applies there too.
* A large refactor/hardening PR is still open.
* That PR explicitly says **Android emulator and physical-device testing are still outstanding**.

We see these as potential blockers for using adopting Featbit as our Feature Flag system. We also see these as potential blockers for using Featbit x Mobile.

Please let us know how we could help, my group is considering an enterprise license and I would love to get these squared away.

[cosmic-flood]

Thanks @lopezm1 for putting together this detailed feedback. We understand why these issues could block your adoption of FeatBit.
Here’s how we plan to move forward:

1. We’ll set up new repositories for the mobile SDK work next week so we can collaborate through PRs. We’d be happy to help review your contributions.
2. We’d like to work with your team on the mobile SDK specifications, drawing on OpenFeature and existing provider implementations. We can contribute our experience with FeatBit’s SDK design and backend behavior, and help identify and address potential issues early. The concerns you raised around persistence, stale flag removal, releases, and device testing will be part of this work.
3. We really appreciate your offer to contribute. Your team’s experience with Swift and Kotlin, especially language-specific best practices and architecture, would be very helpful.
4. We’ll also follow up with the customer behind the existing SDKs to understand their latest progress and outstanding PRs, so we can build on their work and coordinate our efforts.
5. For Golang, we also plan to complete the OpenFeature provider soon.

[lopezm1]

Lovely, thank you @cosmic-flood . I will follow up in the next two weeks and find the best way to communicate.

[lopezm1]

@cosmic-flood @deleteLater --- we are ready for the repositories to be created .

One question, are the mobile native SDKs being consumed directly by the openfeature-provider or does it run it's own implementation.

Also, what is the best way to collaborate on this work? Slack? Email? Here?

[deleteLater]

@cosmos-explorer

[cosmic-flood]

Hi @lopezm1 we're still learning about mobile SDKs and expect to share our initial ideas for the SDK specification next Thursday. That should give us a good starting point for discussion and help us agree on a plan for the first version together.

In the meantime, we can exchange ideas over email, Slack, or Teams—whichever your team normally uses—as we develop a better understanding of the mobile SDK requirements.

As with our other SDKs, we'd prefer to keep each SDK and its OpenFeature provider in separate repositories.

[lopezm1]

Awesome. I'll have my mobile team review the SDKs again and prepare any final notes.

We are a slack shop, i'll ask for details in the meantime about setting up a channel between our groups.

Thank you for the update @cosmic-flood

[cosmic-flood]

Hi @lopezm1

We’ve published a first draft of the spec (https://github.com/featbit/sdk-spec/tree/main/client-side/mobile), and we’d love to work through it with you before releasing either SDK. Your input would help us finalize the spec and define the requirements for both Android and iOS.

We’ve created the Android SDK repository (https://github.com/featbit/featbit-android-client-sdk) and started implementation. Our team can lead Android, and we’d welcome your feedback and contributions. Would you still be open to leading the iOS SDK once we’ve aligned on the spec? We haven’t created its repository yet.

We could start the discussion on Slack before scheduling a call. Do you have a channel in mind? If not, we can create a private channel in our community Slack.

@cosmos-explorer

[lopezm1]

HI @cosmic-flood - thank you for the mobile spec!

I'm meeting with the relevant teams on Thursday evening. Let me review this with them and I can give you an honest answer after that. But this looks great and should help our discussion a lot.

I will also have an answer for you on the slack channel by then. I'm asking about it.