armv7 support - Githubissues

jdegger commented 4 years ago

Hi,

We are trying to archive our example app, however we are getting an error that the fliclib is compiled for arm64 and no armv7 symbols are included.

Has this been done on purpose or could you rebuild the lib with armv7 included?

ignoring file /Frameworks/flic2lib.framework/flic2lib, building for iOS-armv7 but attempting to link with file built for iOS-arm64

jkichline commented 4 years ago

We still support iOS 9 and 10 with OnSong (more than 25% of our users still use these). Trying to split this out but it would have been better to have backwards compatibility.

AntonMeier commented 4 years ago

I understand the issue and we are thinking about a solution. Basically when we made flic2lib we decided to be aggressive with the OS version since that allowed us to make assumptions in the code to make it more robust and reliable. iOS 9, 10, 11 all had their own share of bluetooth related issues and bugs.

Having said that, I realize now that this might cause more issues than we initially thought. As I described briefly in the OS-Compatibility document, you are able to set the framework to "Optional", which will allow the app to be built for older architectures as long as the framework is not referenced in the code. The reference part you can "solve" by wrapping each framework call with @ available checks. However, it is often easier said than done since wrapping each call can be a real hassle, and that also won't work if you are referencing class names in method signatures, or properties,, etc...

If I were to include slices for armv7 it would make it easier for you to build perhaps, but you would still have to make sure to only use it with our minimum supported version. In that case we would make sure that the manager singleton is always nil on older versions to prevent usage. I guess this is the likely approach that we well go, but we are still discussing it.

If you guys have any ideas on how to better solve it then please let me know!

jdegger commented 4 years ago

Hi Anton, thanks for your elaborate response. The solution you propose seems reasonable for us!

We are also discussing internally to drop armv7 support, we are now checking how big the impact would be if we were to drop armv7 support.

jkichline commented 4 years ago

We will be dropping support for arm7 this year as well, but people are definitely hesitant to upgrade devices. That said, we were able to get this working with a bit of #ifdef arm64 conditional compiles. I also made the framework optional (since I wasn't aware of that) so hopefully that makes the final binary compatible with App Store standards.

jkichline commented 4 years ago

Thanks for the explanation Anton. Having an armv7 slice, even if non-functional would just make the framework easier to use in general. While it would be great if it worked on armv7, it's not a huge issue and we could work around that with @available type statements so it's only available for newer iOS versions, etc.

AntonMeier commented 4 years ago

Ok, good to know! But still, this conversation made me realize that more developers will probably run into the same kind of issues in the future, so I think we need to find a built-in solution.

Again, thanks you for your feedback and patience, it is very helpful to us.

jkichline commented 4 years ago

Just to give you more information... even with the framework marked as optional and embed and sign, when compiling to iOS 9 and 10 devices I get the following error, but I can install to those devices over TestFlight. This is just making me a bit nervous about deploying. The only way I can manually build to these is to remove the embed/sign setting which I have to remember to reenable of course.

Unable to install "OnSong Demo" Domain: com.apple.dtdevicekit Code: -402620391

App installation failed Domain: com.apple.dtdevicekit Code: -402620391 Failure Reason: The application does not have a valid signature. User Info: { DVTRadarComponentKey = 487927; "com.apple.dtdevicekit.stacktrace" = ( 0 DTDeviceKitBase 0x00000001271156e7 DTDKCreateNSError + 109 1 DTDeviceKitBase 0x0000000127115de9 DTDK_AMDErrorToNSError + 792 2 DTDeviceKitBase 0x000000012715556a 90-[DTDKMobileDeviceToken installApplicationBundleAtPath:withOptions:andError:withCallback:]_block_invoke + 164 3 DVTFoundation 0x000000010daec156 DVTInvokeWithStrongOwnership + 73 4 DTDeviceKitBase 0x0000000127155301 -[DTDKMobileDeviceToken installApplicationBundleAtPath:withOptions:andError:withCallback:] + 1589 5 IDEiOSSupportCore 0x0000000126fdda25 118-[DVTiOSDevice(DVTiPhoneApplicationInstallation) processAppInstallSet:appUninstallSet:installOptions:completionBlock:]_block_invoke.352 + 4523 6 DVTFoundation 0x000000010dc1d3ba __DVT_CALLING_CLIENT_BLOCK + 7 7 DVTFoundation 0x000000010dc1ea92 DVTDispatchAsync_block_invoke + 809 8 libdispatch.dylib 0x00007fff64b67583 _dispatch_call_block_and_release + 12 9 libdispatch.dylib 0x00007fff64b6850e _dispatch_client_callout + 8 10 libdispatch.dylib 0x00007fff64b6dace _dispatch_lane_serial_drain + 597 11 libdispatch.dylib 0x00007fff64b6e452 _dispatch_lane_invoke + 363 12 libdispatch.dylib 0x00007fff64b77a9e _dispatch_workloop_worker_thread + 598 13 libsystem_pthread.dylib 0x00007fff64dc26fc _pthread_wqthread + 290 14 libsystem_pthread.dylib 0x00007fff64dc1827 start_wqthread + 15 ); }

Details

Unable to install "OnSong Demo" Domain: com.apple.dtdevicekit Code: -402620391

App installation failed Domain: com.apple.dtdevicekit Code: -402620391 Failure Reason: The application does not have a valid signature. User Info: { DVTRadarComponentKey = 487927; "com.apple.dtdevicekit.stacktrace" = ( 0 DTDeviceKitBase 0x00000001271156e7 DTDKCreateNSError + 109 1 DTDeviceKitBase 0x0000000127115de9 DTDK_AMDErrorToNSError + 792 2 DTDeviceKitBase 0x000000012715556a 90-[DTDKMobileDeviceToken installApplicationBundleAtPath:withOptions:andError:withCallback:]_block_invoke + 164 3 DVTFoundation 0x000000010daec156 DVTInvokeWithStrongOwnership + 73 4 DTDeviceKitBase 0x0000000127155301 -[DTDKMobileDeviceToken installApplicationBundleAtPath:withOptions:andError:withCallback:] + 1589 5 IDEiOSSupportCore 0x0000000126fdda25 118-[DVTiOSDevice(DVTiPhoneApplicationInstallation) processAppInstallSet:appUninstallSet:installOptions:completionBlock:]_block_invoke.352 + 4523 6 DVTFoundation 0x000000010dc1d3ba __DVT_CALLING_CLIENT_BLOCK + 7 7 DVTFoundation 0x000000010dc1ea92 DVTDispatchAsync_block_invoke + 809 8 libdispatch.dylib 0x00007fff64b67583 _dispatch_call_block_and_release + 12 9 libdispatch.dylib 0x00007fff64b6850e _dispatch_client_callout + 8 10 libdispatch.dylib 0x00007fff64b6dace _dispatch_lane_serial_drain + 597 11 libdispatch.dylib 0x00007fff64b6e452 _dispatch_lane_invoke + 363 12 libdispatch.dylib 0x00007fff64b77a9e _dispatch_workloop_worker_thread + 598 13 libsystem_pthread.dylib 0x00007fff64dc26fc _pthread_wqthread + 290 14 libsystem_pthread.dylib 0x00007fff64dc1827 start_wqthread + 15 ); }

jusefjames commented 4 years ago

Hi, I ran into the same issue. My app still supports devices running iOS9 or newer (armv7 and arm64). I am also using the flic1 framework "fliclib-ios", therefore I used the wrapper file "fliclibWrapper.h" to get simulator support. I now added the fliclib2 framework to this file but with the __aarch64__ macro:

#if TARGET_OS_SIMULATOR
    #import "SCLFlicManagerSimulator.h"
#else
    #import <fliclib/fliclib.h>
    #if __aarch64__
        #import <flic2lib/flic2lib.h>
    #endif
#endif

I am now able to run this in simulator (just using the simulator files from older "fliclib-ios" is fine) and on all devices with iOS9 or greater. If running on a armv7 device of course there is no flic2lib support. Therefore if used the __aarch64__ macro everywhere the flic2lib is used but what I am not sure about: Do I need to use the `if (@available(iOS 12, ))` additionally? I think yes because a iPhone 5s has a arm64 architecture but can still run on iOS9 and the doc says: "The flic2lib.framework's Deployment Target (minimum OS version) is iOS 12.0".

jusefjames commented 4 years ago

Update: Get the same error message when trying to run on a iOS9 armv7 device (iPad 3rd generation) even with the __aarch64__ macro:

App installation failed
Domain: com.apple.dtdevicekit
Code: -402620391
Failure Reason: The application does not have a valid signature.

AntonMeier commented 4 years ago

We will include armv7 in the next release to avoid this issue. Thank you all for your help!

jdegger commented 4 years ago

@AntonMeier Great, when is the next release expected?

AntonMeier commented 4 years ago

I don't know, but I will try and have a fix running today or tomorrow. However, I think it would be nice if I can get your help to verify that the fix works before I release it on github. I'll try to attach a zip in this thread once ready.

jdegger commented 4 years ago

Sure, willing to test of course!

jkichline commented 4 years ago

We will give it a look too!

AntonMeier commented 4 years ago

Ok, I have built a Beta flic2lib v1.0.2b1 (file deleted).

I have not yet updated the documentation in the framework, but here are the changes:

Build target is now iOS 9.0 and both armv7 and arm64 are included. This will make it possible for you to build an application that targets those armv7 devices. However, we still do not officially support any iOS version below 12. The framework will work on iOS 11 as well, but we cannot officially maintain it. Any version below 11, meaning iOS 9 and 10, will not work. Therefore, when you initially configure the manager you will get the manager:didUpdateBluetoothState: as usual, but the state will be StateUnsupported instead of StatePoweredOn. If you try to use the scanForButtonsWithStateChangeHandler:completion: despite this, then you will immediately get a completion with an error FLICErrorDomain with a code FLICErrorUnsupportedOSVersion. So, you can say that we have made it so that it fails in a "nice" way.
Since the framework is now built for iOS 9 as well, we can no longer use the CBManagerState enums. So all the usage of those enums in the framework have been changed to a new enum type FLICManagerState. The former manager property CBManagerState cbState has been replaced with FLICManagerState state. The manager callback manager:didUpdateBluetoothState: that used to include a CBManagerState now contains a FLICManagerState and has changed name to manager:didUpdateState:. This should be a very straight-forward transition for you guys.
Writing the nickname property did not properly handle UTF8 characters of two-byte size (such as smileys). This has been fixed, but keep in mind that syncing with the Flic app might still be an issue until we have updated our app as well. As a side note, a maximum length of 23 bytes applies, this will be updated in the docs as well.
Added a _Nullable attribute on the button parameter of the in the completion of the scanForButtonsWithStateChangeHandler:completion: method.
The uint32_t batteryLevel property has now been changed to float batteryVoltage, since it better represents the data. Keep in mind that we can never make a perfect conversion of battery voltage to a battery percentage, so therefore we provide the actual voltage.
Fixed a bug that caused the isReady property to not update properly on re-connection.

I hope this is not too much for you to read, but I guess point 1 is the main one that needs testing. Let me know how it goes! And since this is a beta nothing is fully decided yet, so feel free to give suggestions.

/Anton

jdegger commented 4 years ago

Thanks @AntonMeier, my coworker @wesdewitte will test this behavior the coming days and report back here.

jusefjames commented 4 years ago

Thanks also for providing a new version. I was able to install and run this on a iOS 9 armv7 device without the error message Code: -402620391 Failure Reason: The application does not have a valid signature. I got before.

I am still using the __aarch64__ macro to not include any of the flic2 framework calls in the armv7 build. Additionally I used the new FLICErrorUnsupportedOSVersion error in case the scanForButtonsWithStateChangeHandler:completion: method is called on a arm64 device running iOS < 12 (or 11?).

One thing I noticed: I cannot upload to iTunes Connect and start testing with Testflight because the info.plist contains a non integer value: "1.0.2b1".

This error occurs: ERROR ITMS-90060: "This bundle is invalid. The value for key CFBundleShortVersionString '1.0.2b1' in the Info.plist file must be a period-separated list of at most three non-negative integers. Please find more information about CFBundleShortVersionString at https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring"

Maybe you can change this so I can start testing using TestFlight on a wider range of devices.

Thanks again for your quick fix...

wesdewitte commented 4 years ago

Build target is now iOS 9.0 and both armv7 and arm64 are included. This will make it possible for you to build an application that targets those armv7 devices. However, we still do not officially support any iOS version below 12. The framework will work on iOS 11 as well, but we cannot officially maintain it. Any version below 11, meaning iOS 9 and 10, will not work. Therefore, when you initially configure the manager you will get the manager:didUpdateBluetoothState: as usual, but the state will be StateUnsupported instead of StatePoweredOn. If you try to use the scanForButtonsWithStateChangeHandler:completion: despite this, then you will immediately get a completion with an error FLICErrorDomain with a code FLICErrorUnsupportedOSVersion. So, you can say that we have made it so that it fails in a "nice" way.

Yes right now the build is successful.

3. Writing the nickname property did not properly handle UTF8 characters of two-byte size (such as smileys). This has been fixed, but keep in mind that syncing with the Flic app might still be an issue until we have updated our app as well. As a side note, a maximum length of 23 bytes applies, this will be updated in the docs as well.

Yes writing the nickname works for me now even with smileys. Update After i set nickname to something like "test flic ?@* (Chinese char)" and restart the app, after that i loop through the buttons but then nickname returns (null)

6. Fixed a bug that caused the isReady property to not update properly on re-connection.

isReady is working as expected now.

AntonMeier commented 4 years ago

Ok, beta 2 coming here flic2lib v1.0.2.b2 (file deleted)

This no longer contains "b1" in the version number so you can release on test flight, but please do not submit to App store.
I removed the codesign from the framework all together. It is really not necessary to include this since the developer will re-sign it on release anyways (Embed & Sign).
After some further discussion we made the decision to cut iOS 11 as well since it in not in anyones best interest to allow usage of a framework on an OS version that have known issues. Additionally, all devices, to our knowledge, that can run iOS 11 are also able to upgrade to iOS 12.

This should make the process for the developer very easy. For iOS 9, 10 and 11 you will get the previously mentioned StateUnsupported if you try to configure or use the manager. As long as you handle this properly you should not have to do any extra preprocessor macros or @available checks. Both armv7 and arm64 slices are included.

@wesdewitte I tried to write Chinese characters to the nickname and it works fine (even when you disconnect the button or restart/reinstall the app. First of all, are you sure that you do not have the button connected to the Flic app as well? Like I mentioned, the Flic app syncing will break those characters for now. We will release an updated app next week.

Additionally, keep in mind that the limit is 23 bytes, not 23 characters. For example:

NSString *myString = @"abc 传传传传 123"; 
NSLog(@"length: %ld, strlen: %ld", myString.length, strlen(myString.UTF8String));

Output: length: 12, strlen: 20

@jusefjames Try and remove the __aarch64__ macro, as you should not need it any more. The framework will handle this for you. Also try if the signing works better in this version.

As always, thank you all for your help!

wesdewitte commented 4 years ago

First of all, are you sure that you do not have the button connected to the Flic app as well? Like I mentioned, the Flic app syncing will break those characters for now

Ah yes indeed i misread it, it was added to the flic app but not connected. After removing it, it works fine!

jusefjames commented 4 years ago

OK, removed all __aarch64__ macros and it works on my current devices iPad 3 (iOS 9.3), iPhone 5s (iOS 12), iPhone 6s (iOS 13) and XS (iOS13). Uploading to the App Store for TestFlight testing works as well now.

Only with Simulator i get a few warnings:

FLICManagerSimulator.m:13:10: Pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified)

but I get a "Uncategorized" build error:

clang: error: unable to execute command: Segmentation fault: 11
clang: error: clang frontend command failed due to signal (use -v to see invocation)

i am using this fliclibWrapper.h:

#if TARGET_OS_SIMULATOR
    #import "SCLFlicManagerSimulator.h"
    #import "FLICButtonSimulator.m"
    #import "FLICManagerSimulator.m"
#else
    #import <fliclib/fliclib.h>
    #import <flic2lib/flic2lib.h>
#endif

AntonMeier commented 4 years ago

The nullability type specifier of that method signature will of course be updated in the FLICManagerSimulator.m once I make a new github release as it is separate from the beta code.

As to your other problem, you are not using it correctly. You may not # import a .m file, which is probably why you are getting a seg fault. You also don't not need any form of #if TARGET_OS_SIMULATOR macros to use flic2lib with the simulator. All you need to do is to include the FLICManagerSimulator.m and FLICButton.m in your project. No header file import is necessary. Don't put the #import <flic2lib/flic2lib.h> in a macro.

jusefjames commented 4 years ago

OK, thanks. I made the changes and now it´s building and running on all devices and simulators. Beta 2 looks good from my side, "failing" nice on pre iOS12 devices, working on iOS12 and 13. I will wait for the official release and then update my app to support flic2...

AntonMeier commented 4 years ago

Good! I am probably going to make an official release within a few days.

AntonMeier commented 4 years ago

This should be fixed with release 1.0.2. If you have further issues you may either re-open this, or create a new issue.

50ButtonsEach / flic2lib-ios

armv7 support #7

Unable to install "OnSong Demo" Domain: com.apple.dtdevicekit Code: -402620391

Unable to install "OnSong Demo" Domain: com.apple.dtdevicekit Code: -402620391