We have a BLE device that works like a Fitness band. I want to pair to only one iPhone from the band. Until the user unpairs from the phone or the user resets from the band, no other iPhone is allowed to connect to the band. As Apple is not allowed to have consistent unique identifiers for a phone, I am not finding to way to maintain a single connection.
Is someone know how The Health bands or rings work to have a single connection?
Related
I am working on an iOS app that detects iBeacon devices around me.
From what I understand, we need to know the specific UUID to scan for them.
for ex here: Search for all iBeacons and not just with specific UUID
With this in mind, I use corelocation and I can detect my beacons, ok!
Problem is, when I try several apps in the AppStore, some of the app can just scan all of my beacons with different UUID (I have more than 90 beacons with 8 different UUIDs)!! how is it possible??
App 1: https://itunes.apple.com/us/app/ebeacon/id730279939?mt=8
App 2:https://itunes.apple.com/nl/app/dartle-ibeacon-locator/id904211297?l=en&mt=8
So my first thought is that they use some kind of private framework from Apple, but if you do that, your app will not allow to be published!, hmmmm...
So my question is, how can they do that?
- Do they have like a list of all UUID from all the iBeacon manufacturers?
- Or they know a way to scan for all surrounding iBeacons UUID?
Can someone pls help me answer the question?
Apple's intention is that you can't find all beacons around you, mostly for privacy reasons, but also to save power. Your app should only work with specific beacons, so you need to set up all your beacons so your app recognises them. You shouldn't be able to detect the beacons that my app uses. So the presence of a beacon will only be detected if the user explicitly downloads and runs an app that is supposed to detect that beacon.
BTW. If you buy beacons, they should come with an application (usually a Mac or Windows application) that lets you change their ID. So if Joe's Carwash application uses beacons, Joe buys 100 beacons, and then sets them all up to he ID that Joe's Carwash app recognises. Otherwise Joe would be in real trouble if a beacon breaks, needs replacing, and then Joe needs to update his app. Instead if a beacon breaks that was set to ID xxxxx, Joe buys a new beacons, changes its ID to xxxxx, and puts it where the previous beacon was.
Scenario: I have 10 venues. Each venue has a 40 - 60 iBeacons installed. As the User enters a museum, the apps shows relevant info that's associated with each iBeacon.
Objective: Don't be tied down to one manufacture or use their SDKs to scan/monitor iBeacons.
Proposed Solution: Have the same UDID# for all the iBeacons. Assign the same Major value per museum. Assign unique Minor value per iBeacon to distinguish between the iBeacons.
Question:
Since we are scanning for the same UDIDs and are not configuring the device from our app, we shouldn't need any manufacture specific SDKs. We should be able to accomplish this by Using Apple's CoreLocation to monitor and range an iBeacon Device?
Well it depends on the manufacturer. Most of the time when you buy the beacons they are running the manufacturer's custom firmware and require you to change the configuration to "iBeacon Configuration" (Usually giving you the options to set the UUID, major, and minor fields) through the manufacturer's custom dashboard. So your correct in saying that all you need is CoreLocation framework to monitor/range beacons but you need to make sure the actual hardware is broadcasting as an "iBeacon Configuration".
Assume a user has two iOS devices that support Passbook and that the user has both registered on the same iCloud account, and has Passbook toggled on for synching with iCloud.
If a user downloads an updateable pass (e.g. has webservice URL) through an app (via link) and installs the pass on device A, will device B go through the motions of registering the Passbook pass using the registration service/get serial number/get updated pass? E.g. from a different POV, must the server assume that the user can synch their updateable pass across different devices, and must it support multiple registrations of the same pass across different devices?
Background:
Our business wants to use passbook, and we naively thought we could use the device lib identifier to distinguish a device. Turns out that within a single update (manual or automatic update) the same pass (e.g. passTypeID+serial combo) can change device library identifer as part of their call to the registration REST service. So we thought we could at least handle this by always updating the most current registration entry with new details so we would at most have one registration.
This breaks if two or more devices can be synched and both automatically go through their own registration processes. Only one of the devices would have it's pass registered correctly, and it would be difficult to predict which device has a correctly registered pass. If this doesn't happen, we can hobble along with our current solution.
We have implemented a Passbook Plaform, and we support multiple devices for each Coupon, here is my example with my Mac, iPhone 5 and iPod.
I download the coupon from the Mac from the URL eg: https://passqlub.com:8443/passGen/Pass.seam?passId=71
Then I have the preview of the coupon and then I click to "Add to Passbook"
Like in 5-10 mins, the iCloud of both devices (iPhone and iPod) sync the coupon in both device. As soon as the coupon is downloaded to the Device, it get registered with to records (same serial, same PassType, but two deviceId and tokens)
If the platform want to send an update, it must get the serial and passtype and iterate over the devices and send the push notifications.
Hope it helps to clarify the sync of passbook on multiple devices.
You are correct in that it is not possible to use the device identifier to distinguish a user or a device. There are two reasons for this, firstly if a user has multiple devices and an iCloud account then the pass will automatically sync across all devices, and all devices will register with a unique device identifier.
Secondly, for security purposes, devices rotate their identifiers and tokens. When this occurs, the device re-registers with a new device identifier. Annoyingly, it does not deregister the old identifier. The only way you discover that a device identifier is stale is via the APNS feedback service. So if you are not regularly pushing updates to the pass, or you are not frequently checking the APNS feedback service, you will continue to accumulate device identifier records, when in reality the number of devices has not increased.
The only reliable way to uniquely target a pass is via a combination of serialNumber, authorizationToken and passTypeIdentifier. These three (or a combination of passTypeIdentifier and either of the other two), can act as a reliable primary key.
You might perhaps want to reconsider your schema and logic for targeting records. Apple's sample Passbook Server code contains a simple but effective SQLite schema for pass records and device records. In this example, device records are indexed by a concatenation of device identifier and serial number.
In any event, you should be considering your pass records independent to your device records. When you wish to update a pass, update the pass record, then identify the devices on which the pass is installed, retrieve their device tokens and send to the APNS server. When each device calls in to retrieve the update, you can always identify the pass record using a combination of serialNumber, authorizationToken and passTypeIdentifier.
We are developing iOS app. In our app, user accounts are connected to phone numbers and our app does sms verification when user start using our app (like snapchat). We only use user's phone number for that purpose. Now, we are going to submit our app for review, should I declare sms capability as required?
Users need to be able to receive very first sms by whatever means, but we don't want to restrict our target devices too much (e.g., iPod touch user can receive verification code using their Android and use our app on iPod touch).
You should only add something to the "required device capability" list if your app can't function without it (or can't function with it).
If your app can workaround the device not having the capability then don't put it in the list. If your app doesn't function without the capability, then add it to the list.
Im currently working on a app that can do the Wi-Fi settings setup process on a IP-camra. Right now i can get the SSID the iPhone is currently on but the Wi-Fi password key still needs to me manually enter by the user.
Is there a way to get the complete Wi-Fi settings from the iPhone (SSID, password, and encryption method). I have seen Withings Withbaby app do it but they are in the MFI program.
Im interested in if the Wi-Fi setup can be done without being in the MFI program? My company currently not willing to spend the money required for enrollment.