Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Objectbox-Swift 1.8.1 Pod still use Objectbox-C 0.18.0 #81

Open
chzhong opened this issue Aug 15, 2023 · 2 comments
Open

Objectbox-Swift 1.8.1 Pod still use Objectbox-C 0.18.0 #81

chzhong opened this issue Aug 15, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@chzhong
Copy link

chzhong commented Aug 15, 2023

Describe the bug
Objectbox-Swift 1.8.1 Pod still use Objectbox-C 0.18.0.

I don't know where is the best place to fire this new issue. See additional context for detail.

Basic info (please complete the following information):

  • ObjectBox version (are you using the latest version?): 1.8.1 (packed with Objecbox-C 0.18.0)
  • Reproducibility: always
  • Device: any iPhone
  • OS: any iOS

To Reproduce
Steps to reproduce the behavior:

  1. Follow the instruction to install objectbox-swift
  2. Check Pods/ObjectBox/Objectbox.xcframework/ios-arm64/ObjectBox.framework/Headers/objectbox-c.h or call obx_version()

Expected behavior
I should see Objectbox-Swift backing up by Objectbox-C 0.18.1.

Code
not appliable

Logs, stack traces
sig fault (detail see additional context)

Note: the loaded ObjectBox C library should be updated.
    Found ObjectBox version 0.18.0, but the minimum recommended version is 0.18.1

Additional context
I'll explain the actual scenario here.
I'm building an iOS app that requires a library built-on Go library (I'm also one of the developer of that Go library).
We are using Objectbox-Go 1.7.0 (with requires Objectbox-C 0.18.1) in that Go library, and use gomobile to generate a iOS framework for the Go library. Since the Go library will fully maintain data, it is not applicable to move codes to iOS level (yes, we've planned Android and PC version that uses the same Go library)

First attempt, build the Xcode project without adding Objectbox-Swift as dependencies. Of course it would failed at link stage because Objectbox-Go requires Objectbox-C and it is not included in framework.

Second attempt, adding Objectbox to Podfile, and explicitly specify version 1.8.1. Build successfully completed because Objectbox-C (Objectbox.xcframework) is now included link options (via linking with Objectbox-Swift pod). Tried to run the app, but the app crashes, complaining

Note: the loaded ObjectBox C library should be updated.
    Found ObjectBox version 0.18.0, but the minimum recommended version is 0.18.1

There is no way to find any iOS-compliant ObjectBox-C binaries in releases.

I'd suggest to have two Pods for iOS:

  • ObjectBoxC, a pod that contains only macOS and iOS Objectbox-C frameworks, releases with ObjectBox-C.
  • ObjectBox or ObjectBoxSwift, depends on pod ObjectBoxC

so that developers can choose specified version of ObjectBox-C and ObjectBox-Swift for development, and to build iOS app with other frameworks that uses ObjectBox.

@chzhong chzhong added the bug Something isn't working label Aug 15, 2023
@greenrobot-team greenrobot-team added enhancement New feature or request and removed bug Something isn't working labels Aug 21, 2023
@greenrobot-team
Copy link
Member

greenrobot-team commented Aug 22, 2023

Thanks for the suggestion! Using a Go library in an iOS app was not on our radar when we first created the Go and Swift libraries.

Providing a separate pod that contains "just" the ObjectBox C library would require changes to how we build and ship the pods so if at all this won't happen soon. @greenrobot

I guess the short term fix is to ensure that all our released libraries require the same ObjectBox C library version.

@chzhong
Copy link
Author

chzhong commented Aug 22, 2023

Thnak

Thanks for the suggestion! Using a Go library in an iOS app was not on our radar when we first created the Go and Swift libraries.

Providing a separate pod that contains "just" the ObjectBox C library would require changes to how we build and ship the pods so if at all this won't happen soon. @greenrobot

I guess the short term fix is to ensure that all our released libraries require the same ObjectBox C library version.

Thanks for the reply.

I've worked around this issue and submit a PR to ObjectBox Go that cause the crash.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants