Skip to content

Drop iOS Application Integrated with Firebase#5

Open
oluiscabral wants to merge 40 commits into
mainfrom
fix-and-firebase/kmp-ios-impl
Open

Drop iOS Application Integrated with Firebase#5
oluiscabral wants to merge 40 commits into
mainfrom
fix-and-firebase/kmp-ios-impl

Conversation

@oluiscabral

Copy link
Copy Markdown
Collaborator

Branched off from the last commit of #4 (ef81c65)

Integrates Firebase Analytics and Crashlytics.

Cover the whole Send Files and Receive Files use cases with Firebase Crashlytics logs

mdrlzy and others added 24 commits January 24, 2026 02:53
- Added NSObject import from platform.darwin for iOS protocol implementations
- Fixed NSMutableData initialization for receive file buffer
- Added ExperimentalForeignApi opt-in annotations
- Fixed UInt/ULong type conversions in use cases
- Configured proper iosMain source set hierarchy in build.gradle.kts
- Added Java 17 configuration for Xcode builds
- Linked SystemConfiguration framework for network monitoring
- Implemented ArkDrop bridge wrapper for iOS
- Added send/receive file implementations for iOS
- Configured cinterop for Objective-C bridge
- Add .github/workflows/release-ios.yml (Testflight, same secrets as Rate-iOS)
- Add fastlane Fastfile, Appfile, Gemfile
- Add shared iosApp.xcscheme
- Update bundle ID to com.arkbuilders.Drop (from deprecated Drop-iOS)
- Update Release config: Team SQNXHTL7FT, manual signing

Co-authored-by: Cursor <cursoragent@cursor.com>
…ties

Gradle will use JAVA_HOME from environment (set by GitHub Actions)

Co-authored-by: Cursor <cursoragent@cursor.com>
- Config.xcconfig: use // instead of # for comment (fix preprocessor directive error)
- Add copyFrameworkForXcode Gradle task to copy XCFramework to path Xcode expects
- Add Gradle pre-build step in workflow before Xcode build

Co-authored-by: Cursor <cursoragent@cursor.com>
Replace custom task with Copy task to avoid project ref at execution time

Co-authored-by: Cursor <cursoragent@cursor.com>
- Match provisioning profile (Drop-AppStore)
- Add XCFramework-Info.plist template for when Kotlin doesn't create it

Co-authored-by: Cursor <cursoragent@cursor.com>
Fixes ios-arm64/Shared.framework not found - Gradle Copy was not copying nested dirs

Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
@kirillt kirillt force-pushed the fix-and-firebase/kmp-ios-impl branch from 0f3433d to 2a09e34 Compare June 4, 2026 18:44
@mdrlzy

mdrlzy commented Jun 11, 2026

Copy link
Copy Markdown

@oluiscabral

I tested iOS app. Logs might be useful.

Receiving files works as expected, but sending files causes crash:

SenderFileDataImpl: Initializing file
SenderFileDataImpl: Created URL
SenderFileDataImpl: File size: 1581467 bytes
SenderFileDataImpl: Stream status: 2
SenderFileDataImpl: Successfully initialized
✅ Successfully decoded QR code (25254 bytes)
⚠️ ArkDropSenderFileDataAdapter.readChunk() error: kotlin.ArrayIndexOutOfBoundsException

thread '<unnamed>' (17417648) panicked at drop-core/exchanges/sender/src/send_files.rs:119:13:
there is no reactor running, must be called from the context of a Tokio 1.x runtime
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
ArkDrop/ArkDrop.swift:1779: Fatal error: 'try!' expression unexpectedly raised an error: ArkDrop.(unknown context at $10a1d4b98).UniffiInternalError.rustPanic("there is no reactor running, must be called from the context of a Tokio 1.x runtime")

It’s strange that I don’t get the same issue on Android. I asked ChatGPT:

The problem is that on Android the Tokio runtime context probably exists either accidentally or because of the current architecture. On iOS, because of the Obj-C -> Kotlin -> Swift callback chain, Rust may be called from a thread without a Tokio reactor.
A more reliable fix would be to avoid using global tokio::spawn / Handle::current() calls in library code, and instead always spawn tasks through the stored Runtime or Handle.
Also, self.runtime.enter() may not be enough here, because it only enters the runtime for the current thread while the guard is alive. If the flow continues later from another thread or callback, the same issue may still happen.

It looks like the issue may be caused by switching threads due to the language bridge or Kotlin coroutines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants