Because iOS simulator no longer supports BLE (I think), I sometimes need to test my internal distribution app (using Expo development server) on a hardware device. But since iOS 16, in order to do this, it is necessary to enable "Developer Mode" on the device. According to the setting's instructions this results in "reduced" security.
Exactly what risks do I expose myself to when I turn on "Developer Mode" on my iOS (16+) device?
Related
I'm working with a fork of this project for Empatica E4 wristbands and I'm unable to make the discover devices work without running the app from Xcode. The situation can be replicated with the original sample project.
When I ran the project through Xcode, I can see the list of nearby devices.
However, when I close the app and ran in from the phone (instead of clicking "play" on Xcode), I can't see any device.
Should I configure something on the Project or own a developer account? Right now I'm not paying a developer account but I thought I could do this without using Xcode to run the app. Thanks.
In short: I can open the app without connecting the phone to XCode but I can't discover devices when I'm not connected to XCode.
More details.
When executed through Xcode on the iphone, the device discover works. On the logs, we can see:
E4tester [didUpdate] status 2 • kBLEStatusScanning
bluetoothd Received XPC message "CBMsgIdScan" from session "Empatica.E4testerCV-central-313-24"
bluetoothd Received 'start scan' request without duplicates for all UUIDs from session "Empatica.E4testerCV-central-313-24"
bluetoothd State of application "Empatica.E4testerCV" is now "foreground-running"
However. When the app is opened on the iPhone (instead of ran via Xcode), we get the following log messages:
E4tester [didUpdate] status 0 • kBLEStatusNotAvailable
E4tester Task <EA813C26-F662-461C-8C47-A97FA7E32BA4>.<0> response ended
E4tester Task <EA813C26-F662-461C-8C47-A97FA7E32BA4>.<0> done using Connection 1
The important detail here is the kBLEStatusNotAvailable status, which contrasts with kBLEStatusScanning. According to their docs this means The iOS device does not support Bluetooth LE, or the Bluetooth LE module is not active. but the device does support BT LE and is enabled.
I opened an issue on their repository.
You need developer's account for testing Xcode apps in devices.
Developer account will give certificates and provisioning to run app in device. There is 2 certificates develop and distribution.
In your case you don't have any apple account. so maybe u are using freee provisioning
Please read this one to understand free provision:
Test iOS app on device without apple developer program or jailbreak
Maybe the capabilites on free provision is limited on debug mode *(runned from xcode)
In the end I got a direct answer from Empatica support team which I think is perfect since I sought an answer from credible and/or official sources.
Still, I would like to thank Antonio for his useful answer as well as Scriptable and Hichem for their messages.
The answer from Empatica E4 team is the following:
#carlosvega If you are working with an iPhone with iOS 11 or 12 you
should add the string NSBluetoothPeripheralUsageDescription in the
Info.plist file. The sample code has been created a while ago before
the privacy string was mandatory.
-- Empatica Engineering Team
We have alot of iPads on different locations, running an enterprise app in Guided Access. Is it possible to auto update the app, our remote access the iPad to update?
You can do both.
There are remote management platforms that allow you to manage your iOS devices; change passwords, lock a device if it gets stolen, etc. They need to be connected to the internet for this to work though, either through 3G/4G or wifi.
You can also set an iOS device to auto-download updates when they become available.
We have an app in Xcode from our old developers. We are in the registration process for an apple developer account, but on internet I read it can take a couple of weeks before it gets approved.
Is there a way I can simulate the app (like with TestFlight) without sending the actual code to potential new developers?
You can't distribute the app unless you have it signed/provisioned with needed UDIDs (which requires developer program). You can deploy it on your(s) device(s) using XCode though.
You should still be able to run the iOS simulator, which is generally the default behaviour for the build-and-run button - you can download more simulator environments in Xcode -> Preferences -> Components if you're missing one that you need.
Update: If you want third parties to run the app, there's no practical option apart from TestFlight. This is because iOS uses code signing to prevent trojan or pirated apps being installed on their devices. In that case you can consider other options which will achieve whatever your goals are, for example making a video of the app in use or setting up VNC access to a machine with the simulator (and code) on it.
I am developing an iOS application that talks to a lightning accessory. Now, when the accessory is attached, I cannot use the lightning port to debug my application in Xcode.
Is there a way to attach debugger to my application when a lightning accessory is connected to iOS device?
or
Can I somehow attach the lightning accessory to my Mac, and debug it in simulator?
I know some people are talking about WiFi debugging, but that is not supported in Xcode 6.
With Lightning accessories, there doesn't appear to be an option for connecting both Xcode & the Accessory at the same time. I think this has something to do with the way Lightning cables require authentication hardware inside (so nobody has been able to come up with a dongle/splitter). The solution I ended up using was a remote logging tool that sends log messages via network to your Mac. I use NSLogger but there is also CocoaLumberJack.
Granted, you have to pepper your code with log messages for this to be useful and there are other limitations, but it is better than nothing. You can also clean up your log messages by using a custom log macro (Objective-C only).
I am attempting the same thing. I could do it on 30 pin device using the CableJive adapter. But there does not appear to be a way to do this with Lightning. I suspect that since lightning connections (including cable) are all secured though embedded serial number chip, it means that the iOS device only allows one authentication chip per lightning connector, which means no splitters / bridges / Y-Connectors or other items unless approved by Apple.
Apple does have some magic devices for MFI approved developers, but my MFI approval expired, so not sure what they have now for Lightning device testing.
You may be able to connect to XCode wirelessly and develop with the accessory connected. This question may help guide that process.
What does the Xcode 4.2 preference "Support Wirelessly Connected Devices" do?
Wireless debugging is now available as of Xcode 9 or later and iOS 11 or later. A nice write-up on how to connect your mobile device to remotely debug are here:
https://medium.com/swiftist/wireless-debugging-xcode-b6e98e26e022
How do you perform wireless debugging in Xcode 9 with iOS 11, Apple TV 4K, etc?
The vibe I'm getting from Stackoverflow and the internet at large is that unless I'm using an LE device, any Bluetooth device I make for an iOS app must be MFi certified.
However, on the MFi FAQ page, I found this line:
...developers of accessories that rely solely on standard technology
(e.g., Bluetooth Low Energy or standard Bluetooth profiles) do not
need to join the MFi Program.
My device will be able to use the standard Bluetooth profile File Transfer Protocol (FTP).
Now this sounds like some conflicting advice to me, or perhaps I'm just not understanding correctly. So, having provided the above evidence, I'm just going to ask outright: Can I write and publish an iOS app that connects to a proprietary Bluetooth device using the standard Bluetooth profile FTP without certifying my device as MFi? And if so, what details, caveats, etc do I need to know?
The new Bluetooth 4.0 Low Energy (hereafter BLE 4.0) specification which is implemented in Apple's latest iOS devices does allow one to create app-specific profiles and connect to BLE 4.0 devices without jailbreaking, using an approved Bluetooth 2.1 profile, or becoming part of Apple'd MFI program and using the previously required MFI cryptographic chips.
In other words with the proper BLE 4.0 compatible bluetooth radios you can create wireless devices that connect to iOS apps without having the device pre-approved by Apple. However, you must write a custom app for the device, and Apple still holds the ability to reject that app if they want to. So they still control this to a great degree. This is essentially Apple's answer to the Android ADK, while not fully relinquishing the ability to shut down apps and devices they don't like.
Your app must include specific XML schema for your app's bluetooth profile, and use CoreBluetoothFramework APIs, so it's very obvious to Apple during the app approval process that your app connects to a device. If your app does not work without the device present, then it's likely to be rejected if you are not part of the MFI program, as Apple cannot test the app without your device. The apps that appear to be successful in passing this test use the device as an accessory to app functionality, rather than a requirement. For instance an exercise app might connect to a BLE 4.0 heart rate monitor, but the app doesn't depend on it.
Some apps seem to be getting around this by displaying simulated, or online information in place of the device information when no device is present. Thus the app can be tested without the device, and functionally works when the device is present.
You can find out some successful efforts online:
http://blog.makezine.com/2012/03/19/bluetooth-4-0-from-arduino-to-iphone-no-jailbreaking-no-mfi/
BlueGiga in particular has been pushing their devices specifically for this use, so there are probably forums and support for this elsewhere.
Keep in mind that the devices that currently support BLE 4.0 are limited, and currently only include
iPhone 4S and later iPhones
recent MacBook Air, Mac Mini
iPad (3rd generation and later, and iPad mini)
Macbook Pro Retina
There may be other Apple devices that support this standard, it's something Apple is advertising openly on each product's technical specifications page so it's easy to find for current products.
That line is referring to standard profiles supported natively by ios devices, such as HFP or A2DP. If you build a headset device that does HFP, the iphone will be able to connect to it and route your call to the headset without the headset being part of MFi.
If you want to write an app that does other things with bluetooth, inlcuding FTP, you would have to use MFi.