I know there are quite a few threads on this, but it seems none of them would satisfy what I am trying to look for. Here's my constraints:
not a hack that uses private API/framework or undocumented
directory access that would run the risk of app being rejected
because of that
being able to share data across different
vendors / app developers
data can persist outside the lifecycle
of the app (even after app is deleted)
UPDATED: I was in general trying to stay away from using a 3rd party cloud-based service to achieve the goal as this would introduce additional external dependency. But if I have to, I was hoping it could satisfy this one constraint
being able to tell which iOS device it is communicating with. It shouldn't have to uniquely identify the device (which will go into that evil UDID discussion route as we all experienced ). But as long as it can differentiate among different iOS devices it should be fine.
I kind of need this too. I use Parse.com as the backend of all my apps — their free tier should satisfy your development needs.
Parse has APIs available for iOS, Android, Windows 8, OS X, JavaScript and .NET, with all your data available on the cloud on any platform (contrary to Core Data and iCloud). They also offer "Cloud Code," which is code you can execute remotely, to process information remotely and get the data back to your app.
You should definitely check Parse.com out for cloud storage for your app. In my experience, it really gets the job done.
For Data Persistence, I think you might want to take a look at FMDB (although if you decide to persist data locally, it will get deleted with your app, but it might help you, anyways). Core Data is an overkill in many cases.
Edit: Parse.com has an "Installation" class, in which all the devices that have your app installed get listed (wether they're running iOS or Android), uniquely, without you having to type any code.
Maybe this blog post by TextExpander authors will help:
Smile has responded to this by discussing the issue with Apple
engineers at WWDC, filing a bug (#14168862), and checking up on the
status of that bug. We also developed a workaround by storing the
TextExpander data in a new place. Reminders requires user consent to
store and retrieve data. Completed reminders are not normally shown in
its interface. Long-past reminders appear at the bottom of the
completed reminders.
TextExpander touch 2.1 (and later) supports storing shared snippet
data in a long-past, completed reminder. We produced an updated SDK
and kept our developers posted on its progress. Our final SDK was
ready within a few hours of the end of Apple's official iOS 7
announcement.
UPDATE (22.11.2013)
This might not be the best way to do that, because TextExpander's team recently had problems with the App Review Team.
Edit: this only works for apps with the same vendor.
You can save a password to the device's keychain, then access that password from any app.
Using the SSKeychain library...
NSString *service = #"com.yourcompany.yourservice";
// read
NSString *password = [SSKeychain passwordForService:service account:#"user"];
// write
[SSKeychain setPassword:password forService:service account:#"user"];
The password string doesn't have a length limit, so encode all your data as a string and save it there. The keychain entry will persist after the user deletes the app.
One of the ways to do this is using THRIFT. This is a data communication protocol that would need a back end server (private) and THRIFT can be compiled into many languages / platforms. There is a meta language to describe the data and then can be thrift compiled into many languages. Write the data definition once and can be used on many platforms.
More information at.
http://thrift.apache.org/
for me (I have 2 apps and a widged) the best solution is using SSKeyChain and do not forget to add Capabilities for your apps like here
or if you don't wanna to use 3rd party library you can use NSUserDefaults and set the group identifier like here but again do not forget to add the group identifier in Capabilities in AppGroups section for all your apps that have share data.
Related
My GoogleService-Info.plist file for iOS was stolen, is it possible to disable access to my Firebase Firestore to all current iOS devices, and reset this file ?
I tried to delete my iOS app in Firebase, but I can still make request from my iPhone...
And I need to disable access only for iOS devices not Android.
As Doug Stevenson pointed out the contents of the GoogleService-Info.plist are public and accessible to every iOS user of your application. Therefore it is inaccurate to say they could be stolen as they're already publicly available.
As explained in the Firebase documentation the file fields contain identifiers used by your application and Firebase servers to route the requests being made to Firestore, Real Time Database and the rest of products the app might be using. Reading the documentation or the post shared by Doug you would see the information exposed is not a security threat.
Moreover, I would like to point out that everybody could try to access your Firestore collections and try to add/drop data. This is indeed expected as Firestore is publicly accessible by mobile and web clients. However, this doesn't mean Firestore is exposed to users to do whatever they please, instead, the actual access is totally under your control by the means of security rules, which enforce what actions a given user could do. In that sense, the developers who left will only have the access level that your security rules grant them, which shouldn't be a threat when having good rules in place.
Lastly, you may revoke the credentials completely removing the application. I'd say it's not a great idea as you would cause a service disruption to app users. Also, this won't improve security or diminish risks.
You can remove the app directly from the Firebase console
Before proceeding make sure to check and understand the consequences.
Click on Settings > General;
Scroll down to Your Apps;
Identify the app and click on Remove this app.
I am trying to build a mobile monitoring tool/app for iOS without Jailbreak. The only possible way to perfectly access all installed app's content is through iCloudKit.
Also I found Apple's MDM come a little close to this for BYOD devices but yet accessing individual application's data is not possible.
During all this process, I came across some website fonemonitor and phonemonitor (with and without) who claim to do the same without Jail Break.
So here is my question is it possible to take any application's data if we get access to the users iCloud account? Also, are all public, private and shared data accessible via iCloudKit? As the documentation clearly states private data is untouched.
How does app monitoring work for any iOS Devices through these websites. Any lead would actually help!
I have a requirement to remove all API keys and app secrets from the source code of the app we are building. Ideally the keys and app secrets should be sent to the app out of band as a configuration file, through an MDM solution.
Is this possible, and if so how? If not, what is the recommended approach to store this kind of information, such that it cannot be viewed in the source or extracted from the binary?
EDIT: Update
It is possible to send NSUserDefaults to the app via the MDM solution using Managed App Configuration. However, NSUserDefaults is not secure, easily viewed and modified by a casual user.
My plan is to encrypt the NSUserDefaults to prevent this using the common crypto library included in iOS. Is this the best approach to this problem? Should I also be sending a certificate as part of the MDM config?
Any thoughts, comments, and recommendations appreciated before I go too far down this route.
I know it's been a while, but I recently looked into this (not for an MDM application). I don't have any experience with MDM and that may have another solution. The route I chose to go was using CloudKit. It's a 1st party solution, always available whether the user is logged in to iCloud or not and you communicate securely with Apple's servers and only your App can access these keys.
Also depending how you set it up you can easily rotate out keys.
See more info here
I'm new to mobile programming. Recently my company has looked into creating a specific application for tablets (Android and iOS). So it was assigned to me to develop a thin-client based around using HTML5 for what we need to do.
Essentially the application allows a user to fill in a custom-designed form (which the user can build themselves, or pull down a predefined template from our server). This form is built using HTML5, Javascript, JQuery, etc. Some additional functionality is planned, such as being able to take a picture using the native device and attach it to the form that we send back to our server for storage (once we figure out how to do it in iOS. We've already done it in Android.)
However, I noticed the following on Apple's App Store Guidelines, under the Functionality section. Item 2.12:
Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected
Can someone explain, or at least direct me to clarification of this when using the UIWebView construct? This application at its core is pretty much just HTML5. While it might have some additional bells and whistles, does this mean that if we try to submit this (when its completed) to Apple, that they will simply reject it out of hand? Implementing the majority of it in HTML5 was done purposely so we wouldn't have to re-code everything from device to device (and we will also embed it in one of our products, so if they want to fill it out on the desktop while in our system, they can.)
Any guidance would be appreciated, or even suggestions of where this question should be asked if SO is not the proper forum for it. Thanks again.
The key in the Appstore guideline is the word "simply":
Apps that are not very useful, unique, are simply web sites bundled as
Apps
If you keep a balance between locally stored and remote HTML content for your webviews Apple would not look at the app as a hollow shell pulling in remote content.
How can I privately share data between two apps on the same device that have different team IDs? We used to do this via the pasteboard, but with iOS7 to use app-specific pasteboards they now have to have the same team id.
The problem we are trying to solve is the unlocking of features in one app if the user has purchased another app. We'd like this to happen quietly in the background (hence originally using app-specific pasteboards) but having some security to prevent users from spoofing the process and unlocking features.
One approach we are investigating is to use a system pasteboard but to encrypt the data with a device specific key. As long as both apps use the same algorithm to generate the key this should work, but he problem then becomes how to generate an app specific key.
Any advice/guidance on the best way of enabling this sort of feature unlocking scheme would be very helpful.
I use the pasteboard for sending data between applications as well. It's a really useful tool for sending medium size amounts of data between applications. I actually wrote up a blog post on the topic a while back.
Unfortunately, as you've pointed out, private pasteboards are only available to apps that share the same prefix in their app id. This is typically the Team ID, but may be different if you have an app that dates back to when you could use a different bundle seed identifier.
If you have medium sized amounts of private data being shared between apps with different prefixes then a different solution is in order. In this case I would suggest using some form of encryption and using the general pasteboard to shuttle the data around. Depending on the sensitivity of the data, it probably would be a good idea to encrypt the data even when using a private pasteboard. Rob Napier has a nice library for making the encryption and decryption very simple.
Alternatively, if your data is fairly small you might consider encoding the data into a URL and using a URL scheme to move the data into the other app.