I have a watch app using the same API as it is on iPhone. The request code are total same. But the response time on watch is slower than iPhone about 3-4 seconds. Is this normal? Can we improve this experience on watch?
Thank.
First, comparing Apple Watch's speed with iPhone, no matter what area that is, is pointless.
Apple Watch is smaller in size, which has less battery, less CPU power and a much smaller antenna. It should be so much slower than iPhone. That's part of the reason it's been locked out from lots of standard iOS APIs. You already saw how slow when it loads an app before 3.0 beta.
Secondly, although Apple Watch support WiFi, unlike iPhone, it supports only 802.11b/g/n 2.4GHz. Not 5GHz or ac.
Keep in mind that it's an extension of your iPhone, not a standalone device that to be used extensively like you do to your iPhone. If it's slow, maybe you shouldn't let it do it at the first place. Instead, use your phone to do the work and send the data to your Watch.
Related
I am working with ibeacon. I created an application for tracking devices. But I am facing a problem with the application. The app works well in the terminated state for iPhone SE whereas it is not working (in the locked state) for iPhone 7+.In the unlocked state it is working for 7+ also but still it is very slow compared to iPhone SE. Is there any specific reason for this problem. If it can be solved, what could be the possible solution to this problem.
I am really helpless and clueless about this issue.Please do help me and assist me with your knowledge Sir. Thank you in advance.
When an iOS app is in the background, it relies on two different mechanisms to detect beacons:
Hardware filters. These are byte patterns stored on the Bluetooth chip that alert the OS when a BLE advertising packet is received that matches your beacon region. This mechanism is very fast and delivers results within a second, but it is a limited resource. Once all slots are full, it will no longer work. There is no documentation about the number of slots available on each iPhone model, but experiments suggest the number is ~30.
Software scans. A full BLE scan is performed to find all beacons even if they are not stored in a hardware filter. In the foreground with ranging active, software scans are constant. In the background they are periodic to save battery, so detections based on software scans are much slower. The rate is undocumented, but experiments suggest software scans are performed every ~10 minutes in the background in the typical phone state. An additiona softwarel scan is also performed when the screen is unlocked.
The problem description is consistent with hardware filters (1) not working on the iPhone 7+. This may not be a problem with the phone model, it could be a problem with the specific device, or more likely the software state on the phone. A typical cause is the installation of multiple beacon apps that use up all the slots. Each beacon app can register up to 20 beacon regions for monitoring, so just two apps could use up all the slots!. The first apps to run and register slots may hold them forever.
A few troubleshooting tips:
Uninstall any other apps you think may. be detecting beacons, then re-install yours.
Restart your device.
If the above does not help, you may have a hardware problem with your device. Try another iPhone 7+ to see if you can reproduce.
I need to set a timer to lock an iPhone from my app. While using the application, after 3 to 5 minutes the phone should become locked.
Short answer: You can't.
Long Answer: For the security of iOS users, Apple does not allow any application to work with important hardware matters, such as locking the iPhone or controlling the usage of other apps. If your app even attempts to do such a thing (using any method, like external APIs), your app will immediately be rejected by Apple. It is not even worth trying.
You cannot lock the screen programmatically without any private API. Even if you use a private API, your app may probably be rejected by App Store.
However you can indeed achieve by sending keyboard events from paired bluetooth hardware devices. But that means your code depends on a Bluetooth connection and I cannot think of any practice use of that. To do this with Bluetooth, click here.
Does anyone know of a faster way of getting data from the Apple Watch that is faster than the Watch Connectivity framework? I'm trying to access the gyroscope and accelerometer data in real time (or as close to real time as I can get) and the Watch Connectivity seems to be operating very slowly. The console in Xcode is able to receive data very fast from the watch. Is Apple using another type of communication that hasn't been opened up to developers?
I'm working in an academic proof-of-concept environment so it doesn't have to be elegant. I've tried some libraries like ilibmobiledevice and node-ios-device that pipe device syslogs into Terminal, but neither seem to be able to support AppleWatch. I've also looked at some UDP options but that looks to be shut down on the AppleWatch as well...
So far, I've found that the only viable solution "should" be the MultipeerConnectivity framework used on macOS, iOS, and tvOS to communicate over WiFi.
Unfortunately, it seems that the reason Apple don't implement this for watchOS is because it is too demanding on the Watch battery, hence why WatchConnectivity and low-level Bluetooth is the only option. Apple have weighed power consumption against transfer rate and clearly decided that MultipeerConnectivity isn't possible.
I am writing a Core Bluetooth App for IOS. It is connecting to a TI device With custom firmware. The firmware developer developed it to publish data 12 times a second. I am using the Notify Property to get the data, but it seems that we are grabbing the data 30 times per second. This is causing extra power consumption, and for specific reasons, I can't pull at my own rate I need to pull at the rate of the device is publishing.
The firmware developer created a Windows Application that doesn't have this problem without having a hard coded Read Rate. So it is On me to find the issue.
Does anyone have any recommendations?
For what you are describing, on your system the Swift side is just receiving notifications, so there is no control over the rate that your device is using to update that specific characteristic.
But, some devices may have a command on their own high level protocol to set the advertising interval. That's completely up to the manufacturer. If you think that the system is advertising at a different rate with that Windows app that you have mentioned, I would suggest to take a look to see if there is any initialization code that the app may be doing when it starts (thus setting the rate). But for that you will need the Windows app's source code, or at least the manufacturer's documentation about your device's protocol (if any).
Also, are you really sure that the updating rate when the device is connected to the Windows app is really lower than the one you are experimenting when connected your iOS app? How are you measuring that?
I'm learning iOS development and I need to know what hardware I need to test my apps.
Is the iPhone/iPad simulator in Xcode sufficient? Or do I need the hardware? I have an iPad 2, and an iPhone 3G. The iPad 2 is one generation old, while my iPhone 3G is three generations old.
My first project is a basic card game with networking, based on a tutorial.
Opinion: Considering the number of questions I see of the form "this works great on the simulator but not on my device" I'd say that having hardware for testing is necessary. I don't think you need every possible device but certainly ones that cover the features that your app uses.
It depends on features you need.
Example of things you can't test in the simulator:
Push notifications
Performance of an OpenGL game (usually you need a wide set of device to test OpenGL)
The simulator can be used for development, but the simulator is not relevant for efficiency. It is very recommended to testing on a real device too. Some of the services can not be developed on the simulator:
the push notifications
in-app purchase
iCloud services
And you know, that the iPhone 3G is not able to be updated for the lastest iOS (your iPad is able).
The first answer is YES, you need hardware as there are differences between the behaviour of the simulator and the devices. They won't always act the same as the simulator is a bit more forgiving than the device.
For example the simulator will find files (images/sounds/models etc.) even if the case is different between the request and the file name, the device will not find them. And there are more.
An other point is whether to buy/have devices to hold different iOS versions. I don't have them all as this is too expensive for me but I can say that this is a problem. No matter how much you will try to consider the differences between the devices you will always miss something and your app might not work or crash on this device.
Still you can consider this question by looking at the apps that you are going to work on. I would say that if your apps don't use the device hardware (camera for example) and don't have features that might cause problems on different devices you will be able to start with out the devices.
Bottom line is that if you want to deploy good working apps, in most cases it will be better if you could test your apps on a variety of devices.
It's not a requirement to have a equipment to test, but certainly very important. You can test FPS of your app, even not containing hand-made OpenGL. All features that you use on your app, like view effects, are tested for sure on a device. Since simulator uses your mac memory, you won't see any side effects from memory shortage. I believe your best chance is to have a iPhone 4 and your iPad 2.