We are currently developing an app for a client in the US, we are based in the UK. We need to "proof" the app as we make changes with our client i.e. get them to check the updates before we go any further.
The issue we're having is that transferring an IPA file to our client has been advised by their legal team as illegal. Is there any other way (simply) to allow our client to view this app regularly as we update it?
Cheers
IANAL, however, their legal team is wrong. When I click Build and Archive, and then Share by Email, the generated email file contains an ipa. This is an Apple-sanctioned method of doing ad-hoc sharing of iPhone apps.
What is probably confusing them is that if you're pirating apps, you use ipa files as well. However, saying that sharing ipa files is illegal is like saying sharing .exe files is illegal. Sometimes, yes. In this case: no, so long as the devices that are running it have been properly provisioned.
Related
I am currently working for a company on a rather big scale e-commerce project for iOS. Of course, they want to publish their project under their iTunes account. My concern is, all I want to do is to develop the project and upload the project in their behalf, from their account and keep my code to myself, just in case they want to do a similar project.
Will my ipa or code be safe? Any way they can reach the ipa or code only from the itunesconnect account ? Any thoughts and knowledge will be great from experienced developers.
Your client must use Application Loader
They have to give you an App Store provisionning profile
Archive your app with "com.compagny.appname" with the provisionning profile
Organizer should open after the process. Select your archive and click on Distribute button.
Select Save for Enterprise or AdHoc Deployment
Select the App Store provisionning profile
Save your ipa on your disk (e.g Documents dir)
Open terminal and go to Documents and execute : sudo chmod 755 yourApp.ipa
Send your ipa to your client and that's all !
With this method your client won't get your code
I would recommend having them add your developer account as a developer for them and having you upload it for them. This will reduce any possibility of any issues when you send them the IPA and they upload the file.
Once your IPA is created, they cannot retrieve the source code. They only thing they could do is get the images and the binary file. They could however reverse engineer the binary from assembly but that is VERY unlikely.
Note that is this is an ecommerce application (handles credit cards) and in the US, PCI legal requirements would likely not allow them to have you upload anything, nor for that matter not have the source code. Their legal team should know this.
I have an iPhone app that I'm distributing to testers. I followed these instructions:
https://developer.apple.com/library/ios/#documentation/ToolsLanguages/Conceptual/YourFirstAppStoreSubmission/TestYourApponManyDevicesandiOSVersions/TestYourApponManyDevicesandiOSVersions.html
And they work except for one of my testers, who does not use iTunes to synchronize his apps. He has many apps already on his phone and doesn't want to synch to iTunes because it sounds like it will delete them. So...Is there any other way to get a testing app onto an iPhone besides synchronizing with iTunes?
Simply distribute it using OTA ("Over The Air" distribution).
When you Archive your application using Xcode (menu Product -> Archive, I hope that's what you do already to keep debugging symbols so that you can symbolicate crash logs when testers send some back to you!), once you click on "Distribute", select the "OTA Distribution" option and follow the steps.
Don't forget to check the "Distribute for Enterprise" checkbox in the appropriate step and fill the requested informations (Product Name, URL of the IPA when you will upload it on your server, etc).
Once your .ipa and the associated .plist is created, upload them both on a web server, and make a link to "itms-services://?action=download-manifest&url=<the_url_to_your_plist_file_here>".
When the users will open this link from their iPhone, it will prompt to install the application on their device directly, without the need to plug their device to any computer.
There are many tutorials on the net about this, simply google about iPhone OTA distribution.
I strongly recommend TestFlight. It's free and it's easy and they manage all that server side work.
Since your user is afraid of the iTunes Sync Process (for good reason), why not recommending him to use the iPhone Configuration Ultility.
That tool does not do a complete sync but only transmits the app you specified to.
It is free, easy to use and very reliable. Well, sometimes it has its hickups on Windoze systems but that seems to be a normal experience for users of that OS.
I've gotten a couple of bug reports from customers that I am unable to duplicate with my devices. These aren't crashes hence no crash reports. I'm trying to figure out what options I have to solve these bugs. Keep in mind that these customers vary widely in their technological prowess and willingness to help out.
The best I can think of is making an ad-hoc build with logging enabled to a file in their documents directory, but then I need a way to get that file off their phone.
Specifically, Short of remote debugging (that would be great) I want to get a log file or some other diagnostics to see what is going on.
What options do I have?
EDIT: Great information already given, but I am looking for something like 'writing log statements to a remote server', probably just for an ad-hoc (for debugging) build. So, basically, by looking at their log, hopefully, I can deduce where things go wrong. I could build such a system, but wondering what is already out there.
Once you have the ad-hoc build, you can send the app to your customers, so that they can install it in iTunes and from there on to their iPhones.
Dragging/dropping on iTunes your app will place it in the App folder.
As to retrieving your log file, you could implement copying of your log file back to itunes (like many apps do), so the customer could get it from there and send it back to you... or you could simply post the file through HTTP to a server of yours under the customer's control.
AdHoc + TestFlightApp.com - extremely easy, powerful.
Flurry is an option.
Greetings,
I'm in the progress of writing a web server script that lets you create custom iOS apps (basically exchanging logos and a few other things). The web server customizes a previously uploaded "shell" .ipa and re-zips the whole container to send it to the user's browser. That is: we customize a previously uploaded .ipa on the web server and let the user download it for submission to the App Store.
The next step would be to re-codesign the whole .ipa - because we changed the .IPA contents and the user must use his own signing identity - so that he can actually upload it to the App Store.
From what I understand, there is a "CodeResources" file which contains some kind of hash for each resource file in the bundle, and the executable contains some kind of embedded signature as well. To generate these, you'd have to use the "codesign" utility on the user's computer, then use Application Loader to submit it to the App Store. Correct so far?
What I'm trying to find out is:
Is there a way to codesign the .ipa on the server (with having the user upload his certificate beforehand), so that he does not have any extra work to do?
If 1) is not possible, is there some kind of tool that allows to re-codesign the .ipa without much hassle? Xcode seems to require some project setup work to do just a bit of code signing - if possible at all.
Are there any alternative ways to codesign the .ipa files for the user - possibly without having to manually do it by hand?
Thanks in advance!
Xcode uses the codesign command line utility to create the CodeResources folder and the digital signature, you can invoke it yourself to sign an app bundle outside of Xcode. You could probably automate this on a server if the server was running Mac OS X; if you're really clever you might be able to figure out how to create the signature yourself using openssl (the signing certificates, etc. are all standard stuff). Or, if you can count on the user having the dev tools installed, provide them with an app that automates the signing for them.
Here's a blog entry describing some of the process (though the use case is a little different).
I don't like to answer my own question, but I want to close this after so long.
We ended up using Xcode's targets and schemes to ease up the generation of many different apps. Since we have a reasonable number of app variants, this seems to be OK for now.
Code signing is a mess and Apple constantly changes the technical process behind it - so it's a moving target and requires a lot of hacking and trial-and-error work.
Grepping around, I see that I'm not AT ALL alone in being... challenged... by the process of setting up an iPhone app, getting it to run, giving it my testers, and so on.
I've gotten it to work. Somehow I emailed a copy or two to testers, and eventually got my li'l app into the store, and that was fine.
But I can't say a really, deeply understand it! (And I don't do iOS dev every day. Even now my recollection of what I did is kind-of hazy.)
I'm moderately capable of understanding things, if presented, well, you know, in a way I can understand.
Can anyone point me to a crystal clear explanation of what provisioning actually is?
I feel that if I understood it, the recipes to do it would be obvious.
Thanks!
Development provisioning profiles sign your application, and allow the phone to know it's OK to run. These days, XCode automatically makes a Development Profile for you (the "Team Profile").
The other kind of profile, when you are talking about other people running you app, is a Distribution Profile. You need a Distribution profile for either giving your app to the store, or for giving to beta-testers.
The profile is what allows other people's phones to know it's OK to run your app, basically it includes a list of device ID's approved to run that application on the phone in question, along with being signed so that the phone knows the whole thing is valid.
If you read advice around the web concerning distribution, it's easy to get confused because things used to be a lot harder. You used to have to send Distribution certificates separately from your app to beta testers. These days the certificates are included in your app bundle so you don't have to worry about that.
Furthermore, sending an AdHoc build can be all kinds of unpleasant - for testers using Windows. These days, the absolute best way to do beta testing is have a link on the web that uses the Enterprise ad-hoc deployment feature, to let a user with iOS4 or higher automatically download and install your application with no iTunes or copying work at all. In fact I would at this point refuse to use beta testers running windows who were not on iOS4 or higher.
The guide link posted should have a section about the enterprise ad-hoc, but basically the way it works is there's a small plist file the phone downloads, that has a link to the IPA file containing your app. You point the phone to a specially formatted link to the plist file and the phone fetches the application directly.
All of this is predicated on using the "Build and Archive" option for building any ad-hoc distribution build. You should do that anyway because it also saves out a symbol file for you to use in debugging crash reports.
EDIT:
Here's a little more detail on enterprise deployment (which works for any registered developer, not just Enterprise registered developers):
http://jeffreysambells.com/posts/2010/06/22/ios-wireless-app-distribution/
The Developer Program User Guide should be helpful.