Lime 7.8.0 introduces Bluetooth dependencies on iOS that will cause app rejections

[Continuities]

Commit 43666e816d3fd5840dc0858aae420f940e30d4e9 introduces a Bluetooth dependency on iOS that Apple really doesn't like. I don't use Bluetooth, but Apple rejected an app built with Lime 7.8.0 with the following statement:

We found that your app uses GameKit public APIs to change Bluetooth device settings.

GameKit APIs are provided to assist in the creation of social games. Using these APIs for other purposes, such as changing Bluetooth settings on a device, is not prescribed by Apple and is therefore not in compliance with the Apple Developer Program License Agreement, as required by the App Store Review Guidelines.

In particular, section 3.3.1 of the Apple Developer Program License Agreement specifies:

"Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs."

If there are no alternatives for providing the functionality your app requires, you can use Feedback Assistant to submit an enhancement request.

[player-03]

I have approximately zero experience with Bluetooth and haven't interacted with Apple in years, but I wonder if the problem isn't specifically 43666e8, but rather something to do with native-toolkit. I say this because the Lime repo doesn't seem to directly interact with Bluetooth, whereas native-toolkit/sdl does.

From a quick glance at Apple's documentation, CoreBluetooth (which is referenced in 43666e8) doesn't appear to be related to GameKit, so it seems unlikely to be the cause of this error. In fact, neither Lime nor native-toolkit/sdl seem to reference GameKit at all.

My main problem here is that Apple's rejection notice is frustratingly useless. Are they talking about CoreBluetooth or something else? What functions are being called that shouldn't be? Where do we even begin to search for the problem?

Try getting in touch with their support team to find out more.

[Continuities]

I think you're right. I expect it's due to the SDL update that happened in 7.8.0. The changelogs report introducing Bluetooth gamepad support in iOS. Bet that did it.

On Mon., Aug. 31, 2020, 7:17 p.m. player-03, [email protected] wrote:

I have approximately zero experience with Bluetooth and haven't interacted with Apple in years, but I wonder if the problem isn't specifically 43666e8 https://github.com/haxelime/lime/commit/43666e816d3fd5840dc0858aae420f940e30d4e9, but rather something to do with native-toolkit https://github.com/native-toolkit/sdl/commit/370d05558c31570e34c642303705a66a9d0d1547. I say this because the Lime repo doesn't seem to directly interact with Bluetooth, whereas native-toolkit/sdl does.

From a quick glance at Apple's documentation, CoreBluetooth (which is referenced in 43666e8 https://github.com/haxelime/lime/commit/43666e816d3fd5840dc0858aae420f940e30d4e9) doesn't appear to be related to GameKit, so it seems unlikely to be the cause of this error. In fact, neither Lime nor native-toolkit/sdl seem to reference GameKit at all.

My main problem here is that Apple's rejection notice is frustratingly useless. Are they talking about CoreBluetooth or something else? What functions are being called that shouldn't be? Where do we even begin to search for the problem?

Try getting in touch with their support team to find out more.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/haxelime/lime/issues/1429#issuecomment-684091696, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFIQAY53EO2PJQMCLVDDV3SDQVQBANCNFSM4QPZMZEA .

[justin-espedal]

This doesn't affect just publishing. In the right circumstances, it will even cause testing of the app to crash.

played with iOS 12-: works fine
played with iOS 13+:
	built with iOS 12 SDK (Xcode 10) or less: device will ask for permission to use bluetooth, app will keep playing after permission is determined regardless of whether it was granted
	built with iOS 13 SDK (Xcode 11) or greater:
		usage string is included: same as above, I'm guessing? device should ask for permission and everything should be ok
		no usage string is included:
			existing permission set on device: everything is ok
			no existing permission set on device: will immediately crash with privacy violation

In other words, just testing a new app using Xcode 11 and an iOS 13 or greater device will immediately crash.

The fix is pretty simple though. Just change one line in SDL (I've made a PR), and then remove the bluetooth dependency from lime.

https://github.com/native-toolkit/sdl/pull/15

[jgranick]

Try out this commit and see if its working now

(make sure you git pull && git submodule update && lime rebuild ios -clean)

https://github.com/haxelime/lime/commit/ba6fafeefa0ffd4ec2c942eeec341906a9aa165d

[flashup]

Hello, I faced the similar problem.

Compiling iOS project showed me following error on lime 7.8.0:

Undefined symbols for architecture arm64:
  "_OBJC_CLASS_$_CBCentralManager", referenced from:
      objc-class-ref in liblime.a(88920733_hid.o)
  "_OBJC_CLASS_$_CBUUID", referenced from:
      objc-class-ref in liblime.a(88920733_hid.o)
  "_CBAdvertisementDataLocalNameKey", referenced from:
      -[HIDBLEManager centralManager:didDiscoverPeripheral:advertisementData:RSSI:] in liblime.a(88920733_hid.o)
ld: symbol(s) not found for architecture arm64

I switched to the develop branch of lime and tried to recompile lime libs for iOS platform: lime rebuild . ios -clean -v

And there is the error about a joystick:

Error: Error while running command
xcrun --sdk iphonesimulator14.0 clang++ -Ilib/sdl/include/ -Ilib/sdl/src/hidapi/hidapi/ -Ilib/sdl/include/configs/default/ -DHAVE_LIBC -D__IPHONEOS__ -fobjc-arc -c -O2 -fmessage-length=0 -pipe -Wno-trigraphs -fno-stack-protector -Wno-overflow -fpascal-strings -fasm-blocks -Wreturn-type -Wno-unused-variable -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.0.sdk -miphoneos-version-min=5.0 -DIPHONE=IPHONE -DIPHONESIM=IPHONESIM -Wno-parentheses -Wno-null-dereference -Wno-unused-value -Wno-bool-conversion -DHXCPP_M64 -I/usr/local/lib/haxe/lib/hxcpp/4,1,15/include -fexceptions -fstrict-aliasing -x objective-c ./lib/sdl/src/joystick/iphoneos/SDL_sysjoystick.m -o/usr/local/lib/haxe/lib/lime/git/project/obj/iphonesim-c11/1a20c7a7_SDL_sysjoystick.o

In file included from ./lib/sdl/src/joystick/iphoneos/SDL_sysjoystick.m:47:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.0.sdk/System/Library/Frameworks/GameController.framework/Headers/GameController.h:51:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.0.sdk/System/Library/Frameworks/GameController.framework/Headers/GCDevice.h:30:1: error: property with 'retain (or strong)' attribute must be of object type
@property (nonatomic, strong) dispatch_queue_t handlerQueue API_AVAILABLE(macos(10.9), ios(7.0), tvos(7.0));
^
1 error generated.

[justin-espedal]

I looked into flashup's error.

The import of GameController.h is from SDL. The code compiles fine with older versions of Xcode, but with Xcode 12, it breaks. This is because Xcode 12 includes the iOS 14 SDKs, which include GCDevice.h with the problematic line:

@property (nonatomic, strong) dispatch_queue_t [ ... ]

Apparently, dispatch_queue_t is only an NSObject beginning in iOS 6 (source).

HXCPP's iOS toolchains both specify the iOS deployment target to a hardcoded value of 5.0 (shows up as -miphoneos-version-min=5.0), hence the error.

Of course lime's native binaries can just be rebuilt with an earlier iOS SDK, and it'll still work on the newer iOS devices. This will need to be fixed eventually, but it's unrelated to the bluetooth issue here.

[CanIGetaPR]

Could we add a compiler flag that turns bluetooth support on and off for ios targets?