I would like to implement a application which backs up all the internal data like SMS, MMS, videos, audios, documents, call history stored in iPhone. But this seems to be not possible with API docs that the apple has released so far ... I have gone through the PDF of Enterprise distribution program and some of the links related to Enterprise Distribution Program, specifies about the Remote wipe and accessing of internal data like Calendar, SMS, MMS etc .... But they didn't mention how to do it programmatically.
Does Apple provide any special privileges like extra API support to access the internal data in their Enterprise Distribution Program?.
Is there any difference between Enterprise Distribution Program and Standard Distribution Program in the development point of view?
And since in-house distribution does not require Apple approval, shall we use some other method which are not officially mentioned in apple docs, to access the internal stored data ..
If so can anyone point out the way to do it?
Any help would be greatly appreciated
awaiting for your response
Best regards,
Mohammed Sadiq ....
You will not get any "bonus api", as there is no api, there's just public one, and private calls. Still, as you will distribute the app on in-house basis, you can use sqlite to get access to sms, calendar, phonebook data. I can't say for sure about other fields, as I don't know the exact permissions of the latest sandbox profile. You definitely can get access to everything on jailbroken device, but that might be not the best solution for you.
Standard and Enterprise are different in that Apple doesn't regulate the apps, as you said, I don't think there are any differences in development (except for what The company needs like internal server access) but there is the difference in distribution. You can't officially get that data programmatically but using undocumented calls sounds like it could work.
Related
I would like to know if it is possible, and if it's ok with apple if my app will use the iPhone's GUID with my server, as I don't want to nag my users for User/Passwords ...
Thanks !
Apple is crazy about privacy and UDID still allows to differentiate devices etc so I suggest to calculate some hash for example md5 and only afterward to pass it to the server. Such approach will guaranty privacy to your users even if your DB will be compromised.
Apple generally allows this and a lot of analytics frameworks use the device ID for tracking purposes.
You should however consider whether your users' data contains any personal information. If this is the case, I would strongly recommend against using device IDs for identification as they might not be really secret, e.g. because other developers need users' device IDs for beta testing etc. Also, other developers transmit device IDs to their servers and could use those to get at personal information from your users.
See this article for a concrete example of how device IDs could be abused.
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.
Is there a way for the developer of an App Store application to tie a sale to an individual user/device ID/Apple account? In other words, a method for the developer to double-check that a specific user has legally purchased the software?
I haven't been able to find a reliable answer to this yet. I'm not looking for specific code examples, just some sort of idea as to how possible (or difficult) this is.
My intent isn't to penalize piracy; it's to be able to provide additional benefits to paid customers. As such, I'm not looking for a way to identify a cracked or pirated version, which I gather has already been solved.
Thanks in advance for any help you can provide!
None of the answers were all the way there, so I'll summarize.
First, as per Tim's answer, Apple does not give you any information to identify customers of a standard app purchase, or to identify one specific sale from another.
However, using In-App purchases provides you with a method to identify a valid purchaser, directly from Apple. The information you receive in this manner is uniquely identifiable; it doesn't give you a user's device ID and/or Apple Store account, but it can be used to verify a specific transaction.
Apple's documentation on verifying store receipts.
You can roll your own system to do this. You're not permitted to look into Apple's information elsewhere on the phone, but you can let your users create an ID in your system, through your application's interface. Gather the information voluntarily from your customer at the time you have them create their Profile on your system. You can get the Device ID, but you may want to collect something like an email address, too, so that you can continue to provide them with consistent service, as they upgrade to a new iPhone, or add an iPad to their fleet of Cocoa Touch devices.
Be sure to use an encrypted http connection when you're talking to your server, so that you don't accidentally expose your customer's information.
To quote "Dr. Touch"...
AntiCrack contains proven technology
to mitigate the risk of your apps
getting pirated by automatic cracking
tools
You do not have access to any purchaser information from the Apple store. Apple considers these customers THEIR customers, not YOUR customers and so will not make any customer identification information available to you...
-t
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 ....