I agree that this question is duplicate. Please bear with me. I was also among you all to believe that is not possible to programatically turn on/off bluetooth.
But using GKPeerPickerController if bluetooth is not on user will be prompted to turn it on. Fair enough to turn on the bluetooth.
I was betting with my belief that we can not turn off the bluetooth programatically as there is no way. But this application does that so I didn't had choice to refuse.
I just want to confirm whether it is possible or not and if yes how to turn off the bluetooth using GKPeerPickerController or any other public api way ?
I know this isn't the answer you want, but no, you can't turn off bluetooth programmatically with Apple-approved APIs.
There have been a number of apps approved on the App Store this year that have done this.
But, they keep getting removed by Apple shortly after release, once they (Apple) realize what's going on. They're certainly using private APIs.
Either developers are foolish enough to think that they won't be noticed, or they are simply hoping to pull in a couple weeks of revenue before Apple pulls the app, which could be enough to pay back their cost, with some profit.
The issue is that there's a number of ways to check whether an app is using private APIs. If developers are using objective-C frameworks in the normal way, that's an easy check. In fact, Xcode does some of this automatically when you use it to upload app binaries to iTunes Connect. But, it's not a complete check. Once at Apple, the reviewers perform another check, which I've been able to deduce is more sophisticated than what Xcode does.
However, that check is still not perfect, and I'm of the opinion that it's not necessarily a matter of a lazy reviewer just forgetting to perform the check. Objective-C gives you some techniques for obfuscating method calls. Depending on how you use these techniques, you might get past the reviewers . In my experience, I have every reason (wink, wink) to believe that Apple is not running every app on a fully instrumented version of iOS, which could log all function calls, and defeat even the best attempt to hide private API usage via obfuscation techniques.
So, I can pretty much guarantee you that this explains the apps you've found on the App Store that turn off Bluetooth. Public GameKit APIs let you turn Bluetooth on, but not off.
Disclaimer: I've never worked for Apple, and no Apple insiders gave me information. But, I have gotten private APIs through the review process.
Please try below code and I think it will also work for you.
Class BluetoothManagerClass = objc_getClass( "BluetoothManager" );
BluetoothManager *btCont; = [BluetoothManagerClass sharedInstance];
[btCont setPowered:NO];
You need to add BluetoothManager class/framework in your project.
Thanks
Related
I wrote a nice app that would simplify life for many - somehow similar to these phone card apps. However, there is one private API function which I have to use to send a hash '#" in a phone call because the receiving hardware requires this. (which is understandably not allowed because of POSSIBLE abuse). But
My app does not missuse or in any way
cause damage.
Certainly the reviewers at apple don't have time to review for each single use of such functions - so therefore my app got rejected by the automated API check (so I assume). Yes I know that these issues are documented well by Apple, but I was hoping they would really "check" abuse possibilities of apps and then reject - or accept if the app is not harmfull in any way. (as happened in a similar case in appstore)
Anyway, if I don't find another solution this app will not be accepted.
What to do now?
Does it make sense to write an explanation comment when submitting to review?
Is there an alternative to send the signal of a # during a call somehow?
Is there an alternative way to sell/distribute apps? Will this affect my future apps to be submitted? What is your experience?
ps certainly, the Android version is available soon...
Thanks!
An option would be to submit it as a bug and request they "support send a hash '#" in a phone call".
You can always try the Cydia store, and probably there are other ways in the jailbreak community.
Is this even possible?
If not I'm really surprised this hasn't been open thru the API yet.
Apple doesn't allow the use of low level network/wifi/cellular api's. Interestinlgy during a previous period, there were apps in the app store that made use of private apis (a few WIFI-Scanners for example). They've all been banded from the appStore by now, as far as I know at least.
Also the newly available (since iOS 4) core telephony framework doesn't offer any methods or properties to serve you the information you're looking for.
So unless you're building a non-app-store-app I don't see a legitimate solution to your problem.
*sam
Several apps in the app store use OS 3 and get signal strength.
Apple fully approves them.
As a developer I'd like to make a few little utilities for myself that use private methods, etc. as I have no intent to submit them to the app store. For instance, at the moment I want to work on an inter-device communication tool (including an iPhone MiFi type implementation).
So the question is, does access to that particular functionality require a jailbroken device? Or are things like that just a matter of using unpublished APIs and such?
It depends on exactly what you need to do. Using unpublished APIs generally doesn't require jailbreaking; you just use the API. On the other hand, if you need root access or want to use privileged ports, then you'll need to jailbreak.
There are two issues. The first is about private APIs - if you use them you don't get on the store, simple as that. I have never heard of jailbreaking being required to use them though.
Then there is distribution. As above, you don't get on the store so you need some other way of loading your apps to devices. If you just need them on devices in your posession and you have less than 100, any developer can do that without jailbreaking. But if you want to send apps to someone remotely, then they would need a jailbroken device.
Not too sure about a MiFi implementation but from what I understand you could make the app do that without jailbreaking. However, if you don't have an active/paid developer account with Apple then you will need to Jailbreak just to load the app on your phone.
Well, based on some class-dump snooping it looks like the Wi-Fi and tethering methods are called on Springboard.app (except for the socks proxy method mentioned by Kristopher Johnson) which requires using the Mobile Substrate libraries and therefore requires Jailbreaking. Boo.
Some of our application is already in AppStore...
But suddenly one thing comes into my mind, that I want to clear before submitting my next application.
The thing is : As a programmer's point of view, should we require to handle if iPhone Device is jailbreaked ? If yes, then how we can tackle with this ?
Thanks in advance....
On a general note, jail-breaking the device is an issue between the user, Apple and potentially the carrier. You are not a side in this relationship, and the user has no contractual obligations to you with regards to their device.
You could choose to attempt detecting jail-broken devices in an attempt to prevent piracy of your app. However:
If the device is jail-broken, there's nothing you can do to reliably verify it's not jail-broken, since none of the OS APIs (including networking) is guaranteed to function as you expect. Your code could be running in a non-jail-broken simulation on top of jail-broken device.
Of course, you could check by attempting to do one of the things you currently know Apple actively prevents apps from doing. However, there's no guarantee that Apple is not going to allow that particular action in future. And, there's the chance that your app might get rejected because you are attempting to do something prohibited by Apple.
There is no official criteria from Apple on what constitutes a jail-broken device and what does not. And even if there was, you are not guaranteed to be notified in a timely manner (or at all) by Apple if they decide to change any such criteria. But even assuming you do get notified somehow, you can't update your app quick enough to avoid falsely detected jail-broken devices, thus potentially denying access to your app to legitimate users.
If you would like to cut off a large group of users, then sure, go ahead and require it.
Unless your application specifically requires it, there should be no reason to force users to have a jailbroken iPhone or a non-jailbroken iPhone.
If you program is legitimate (no private API calls etc), then you should not concern yourself with JB. You don't need to handle anything differently if the users phone has been JB'd. If it has, and your software doesn't run (say memory issues because they are using backgrounder to run 2 other things) then that's their problem not yours. Make your code well behaved, not leak memory, dump cache's etc with memory warnings, and you should be fine.
As you asked for the "programmer's point of view", I'd say: make sure your app runs on as many devices as possible.
Meaning: as long as you app is safe to run on an iPhone whether it's JB or not, I wouldn't care.
One thing I have found, at least early on (not seen it for a while) is that most reports I got of strange behaviour with my app (vConqr) turned out to be from people with jailbroken phones.
That's not to say I think that's good reason to block them. But if you do any sort of custom crash reporting, or other diagnostics it could be useful to log the fact to save time on troubleshooting.
Do a search on the Internet. You'll find several articles that shows some ways you can detect a pirated app. I make no claim on their effectiveness, but I do use some of these in my own apps. These techniques do not try to detect if a phone is jailbroken; they focus on detecting if your app has been tampered with.
I've been doing mobile app development for a long time (2001?), but the systems we worked with back then were dedicated mobile development environments (Symbian, J2ME, BREW). iPhone SDK is a curious hybrid of Mac OS X and Apple's take on mobile (Cocoa Touch).
But it is missing some stuff that other mobile systems have, IMO. Specifically:
Application background processing
SMS/MMS application routing (send an SMS to my application in the background)
API for accessing phone functions/call history/call interception
I realize that Apple has perfectly valid reasons for releasing the SDK the way they did. I am curious what people on SO think the SDK is missing and how would they go about fixing/adding it, were they an Engineering Product Manager at Apple.
The biggest shortcoming in my opinion is support for separating licensing from distribution.
What I mean by this is that it should be possible to download a trial version of an application and later purchase a license for that application (from an API call inside the application or from the app store). This would make it much easier to try-before-you-buy and get rid of the current duplicates of many applications with 'lite' versions.
I think lack of push notifications for apps is the big thing we're missing right now. With push, you can register your application to perform a task (like getting the most recent data from a web service) even when it's not running, at a time and frequency the OS decides is best. In an ideal world, along with the existing concept of iPhone apps loading quickly and resuming where you last left off, this solves the problem of not running in the background. I know some tasks will be more difficult or maybe impossible with this strategy, but it's still a pretty good compromise between third party applications and the iPhone's limited hardware.
Originally push was scheduled for last September, but it was removed from the beta SDK and not spoken of since then.
API's I'm personally looking for:
Apple80211 as a public API (private, current API is fine if documented)
Access to Volume buttons (semi-accessible via Celestial, private, needs new API)
Access to Calendar (private, API status unknown)
Access to Bluetooth + SPP profile (status unknown)
Access to Camera (directly, API status unknown)
Access to JavaScript runtime (directly, not through UIWebView, API status unknown)
WebKit access that's lower-level than UIWebView (private, current API is fine)
Access to Music Library (private, current API is fine)
Garbage Collection.
CoreData is missing.
You've mentioned some of the big ones - copy & paste (or in fact any way for apps to collaborate) is another huge omission.
It also seems to lack a desktop synch framework (at least if it exists I can't find it).
Language independence and especially lack of scripting is another pet peeve - objective-c is all very well but more languages to choose from would be good.
Inability to dynamically extend apps, via scripts or otherwise, is another big omission. This is partly an SDK/OS issue, partly licensing.
My list ordered by priority:
Mapping abstraction (the MapKit looks awesome), but that would require a new Google Maps TOS
Music library
Camera (photo + video) Access to more
UIViews, Apple designed some pretty nice custom ones for their apps
Better UIWebKit abstraction
The features I see missing that it should have is
Access to SMS
Direct Access to Google Maps App. You should be able have access to this so you could extend your application to use the built in features provided by Google Maps.
Access to the Bluetooth functionality of the phone.
Access to the Calendar. Why not allow access to simply post a calendar event for the user.
Access to Active Sync. It would great if we could directly access this and communicate back to the Exchange Server.
Core Image. They provide Core Animation but Core Image is missing. I hope that this is added to the API soon.
These are some of the features that my clients have access for in the past and are supprised when they are not available.
We definitely miss a Calendar API and SMS access. So many applications could leverage such APIs. The iPhone allows users to have everything in their pocket, but it's almost useless as long as developers cannot leverage this integration in their apps.
A language with proper namespaces.
A limitation that bugs me is lack of access to system features that require root or setuid. For example: opening privileged IP ports.
I'm not sure there is a good solution to this, as long as Apple's policy is to keep the device locked-down.
Allow program to set some kind of local timed event for your application to bring up an alert and launch your app if the user agrees (like any calendar app). You could do that with push notifications but there are many cases I'd hate to have to rely on a whole server infrastructure and network connectivity just to basically do some timed thing.
Some idea of what direction the user is facing. I cannot believe the GPS chip the newer iPhones use are not capable of reporting direction.
I would personally love to see
Access to the CoreTelephony Framework (Currently private). Which allows access to all the phone functions (Especially sending MMS / SMS).
Some sort of ability to run stuff in the background. While push notifications is ok for most things, but it is a bit hard to leverage CoreLocation (i.e. have the app show a notification at a certain location). Of course this would probably need an on/off button or app specific like push is.
animation view which will be reduce developer to make a cool app , of course the core business local still need consider more , but the view layer could more easy to use ....