For testing purposes, I need to periodically deploy new builds of my iOS app to the device which has old data in its document folder. I'd like to be able to selectively update part of the data and control keep-new or keep-old behaviour for any files in the document folder.
Basically, the tooling support I want is to update only the data that changed when deploying to device. For example whatever in the dev-machine's Xcode project resource folder that are newer or different from their counterparts (files of the same names) on the device (by date, size, etc.) get transferred and their counterparts on the device get overwritten by those. Everything else is ignored.
An ideal scenario would be: When I hit BuildAndRun in Xcode, Xcode will figure out what data to transfer-and-overwrite-device-files and what not to based on some custom rules.
Is is possible to achieve this with Xcode?
UPDATE
I edited the above text to make it clear that I don't want to add app logic for data versioning. I want this to happen in my build-and-test pipeline (Xcode).
Normally, this is pretty simple. Everything that XCode sends goes in the resource bundle. If you update it on the device, you have to move it to the documents directory, as the resource bundle is write only.
Any resources that you might be updating on the device already need 'does document version exist' kind of logic, the only change you have is to maybe add some modification date stuff.
You do have the option in the run scheme to upload application data to the sandbox directory.
Here is a good starting point:-
http://developer.apple.com/library/mac/#recipes/xcode_help-devices_organizer/articles/copy_app_data_to_sandbox.html
In essence, you can download data from a device in the device manager and create an xcdata package. Edit this to contain just the stuff you want to upload.
You can then either upload this manually or specify it in the Edit Scheme dialog ( under options), so it gets uploaded every time you run the scheme.
Easiest way I see to do it is to encode a version number in the files, and the ones you need to update, you increase the version number on them in your code, so when it runs and encounters a file that has a lesser version number, it deletes or ignores it
Related
I have a project in App Inventor that uses the TinyDB. In this project, I added an extension I couldn't delete and didn't want.
To solve this problem, I made a copy of the app, downloaded the copy as an aia, unzipped the project and fixed the problem, and then zipped it back up.
Then I deleted the copy on AI so I could upload the changed version. Everything went according to plan, and now I have an app with the problem and a fixed project under a different name.
My question is if I delete the problem app and save-as the copy under the original name, will the tags in the TinyDB still be there or will they be in a separate database that I can no longer access?
I tested this question with a simple app I made. Here are the steps I followed, you can skip to the bottom if you want the conclusion:
Methods:
Create a project
Drag in a list view component, two textboxes, a tinyDB, and a button. It doesn't have to look pretty, it just has to be functional
Go to blocks
Add in the blocks below
Build the apk and install it on your device. Store at least 1 tag.
Go back to AI. In the project, click Project>save as... and leave the project name at the default.
Delete the original
In the copy, click Projects>save as... and set the name to the original name you used.
Build the apk and install it on the device. Do not uninstall the first app you installed.
Confirm that the entries you added are still in the app.
Conclusion:
When testing this, I found that the data in the tinyDB would persist from the other version of the app. I think this was because the project name was the same, I was signing the app with the same digital signature, and the tinyDB namespace was the same.
Therefore, it is safe to change the name of the app and then change it back without losing the data on a user's device.
Further steps:
I would also like to test if this works when downloading the aia, unzipping it, and then zipping it back up and uploading it. I think that would yield the same result, but I have yet to test it.
I'm writing an iOS app which needs a ~60MB resource file to work correctly. I would like to provide this file with the app itself, so it can work straight after installing it from the store without downloading extra data at the first launch.
I also want to be able to update such file by downloading a new version of it from a specific URL. I thought the most appropriate folder to store this file would be "Library/Application support", as specified in the guidelines provided by Apple itself.
My problem is that I can't find a way to provide the "Library/Application support" folder with a default population using xcode 9. I don't want to have multiple copies of this file around to avoid wasting space, and I want the possibility to update this file to a newer version, overwriting / replacing the old one.
This might be a newbie question (I'm a newbie of iOS development) but I really couldn't find anything related to pre-populating that folder.
You cannot delete anything from your distribution bundle. It's just not allowed.
So you options are:
Distribute the resource with the app, and create a copy in "Library/Application support".
Don't include the resource with the app, and download it on first run.
You didn't say what the resource is, so I don't know if this would be an option, but... Include only a portion of the resource with the app, copy it into "Library/Application support" and "update it" on first run.
We developed an app for our client and it is now available in the app store. Lets call it the MAIN APP here.
Now the client wants a separate version of that app, without changing anything but just the name of the MAIN APP. Let's call it the ALT APP here.
The MAIN APP has two Xcode projects, one is the older one, the other is the latest, which is the one what I am working on with new features.
I uploaded the first version of the ALT APP before by changing the app name and bundle ID of the older project of the MAIN APP. So you can think of it that the older project of the MAIN APP is now the project of the ALT APP
Now I need to update the features of the ALT APP to the same as the MAIN APP.
One way to do this is to copy paste the source files of the MAIN APP and overwrite it to the source files of the ALT APP but I think this takes time.
The other way I thought of is to just change the app name and bundle ID of the latest project of the MAIN APP, upload the ALT APP and then later on change it back when I need to upload the MAIN APP
But I am afraid that if I kept on changing the bundle ID there will be build problems(although I haven't encountered any yet).
Is there any better way to do this? Thanks in advance!
Make One Project.
Go to Project setting -> Build Setting
Change
Current Project Version
As you want.
Duplicate your 'base' target as you want
Go to Target -> General -> Version
and Write $(CURRENT_PROJECT_VERSION)
Change bundle identifier.
Go to Target -> Info and find 'Bundle name' and change it. That will be your app name.
I wish you can solve your problem.
This sounds a lot like you need to look into branching in your source code repository. Git in particular is suited to pulling individual commits between branches. Thus allowing you to select changes to copy. Providing you are careful about what you are committing.
Ultimately it sounds like your project is going to end up being an old code based with patches and a new code base with new features. Perhaps your client is not clear enough about what they want. Keeping two version of an app current in the app store would be a headache. Far better to retire one and move with the new.
Xcode deleted my project and everything is gone. The only thing that I have is the app in my iPhone 6. So is there any way that I can retrieve the Xcode project of the app?
.. Update ..
i found all the files now i just need to reassemble them in a new project . but I don't know how .
Let's be clear: Xcode did not delete your project, you did, perhaps inadvertently. This does happen to most of us.
The answer is to recover from your remote Git repository or recover from Time Machine or another backup. If you do not have any backup this is your first warning that you need a backup strategy. Make this your last such warning by immediately, as in right now, creating a backup scheme, preferably two. Little is more important.
There are free remote Git repositories such as BitBucket. Setting up Time Machine is simple, just get an external disk, connect it and you will be prompted. Or use another backup scheme such as BackBlaze.
Without a backup you can recover the assets but not code from the ipa from your phone. If you are using the Asset Catalog that is not easy but can still be done.
Unfortunately,
There is no current way to un-archive an app. You must have the .xcodeproj file in order to make changes. The .ipa is useless in terms of editing or changing your app. And if there was a way to do so, it could and would be abused and many clones/copy's/fakes of popular apps will be published. The only accessible files are things in the Main Bundle which only include, .pngs, .jpg, .txt etc but no source code.
I'm using git with an iPad xcode project.
I have an application settings plist file (AppSettings.plist) that is included in the projects repo.
I'd like my devs to have this starting AppSettings.plist when they do a fresh clone but I wouldn't like this file to be committed each time it's updated, so each dev can keep their own version.
I though about .gitignoring it and supply an AppSettings.plist.dist but how could we remember the builder guy to update this file each time we want to have him to ?
So you do not just want a static template of the file, but you also want to modify the file and get these modifications merged into the working copy?
Note: Let’s call AppSettings.plist “working copy” and AppSettings.plist.dist “Template”
My proposal would be to add a version number to the file. When you do changes in the repo, you increase the version number. Then when building you check these numbers in the working copy and the template and emit an error if they don’t match.
If you don’t care about newer/older, you can also use git’s ident feature. That will add the blob id of the template to on checkout. If that id is not the same in the working copy, it is obviously not based on that template.