I am trying to figure out if I am in a potential bind here. I am having someone else develop my app and I have given them complete access to my developer account to create the certificates to build the binary. I have uploaded the binary using the Application Loader and it it now waiting for review by Apple. My question is when it comes time to update the app, will I be able to do so without using the programmer who signed the certificate? When I become competent I'd like to do this myself but I'm clearly not there yet. I don't want to be in a situation where I have to keep going back to the same programmer to do the smallest thing.
Yes, provided you:
Have them send you the signing assets as described in "Exporting Your Code Signing Assets to Your File System" in the Xcode documentation. Note that they will still be able to sign using your key.
Have them send you the original project, obviously.
Once you part ways with them you should change the passwords of any accounts they've been given access to, like Apple ID and iTunes Connect.
At a later date, or as a last resort, you can create new signing assets as described in "Reset You Signing and Provisioning Assets..." in the Tools Workflow Guide.
So, most important going forward, they must not have access to any Apple accounts belonging to you.
Related
I have a little problem and I am wondering if this is possible. I have just finished updating an app with push notification for a client. I don't have a hold of the server side so I tested the push by modifying the app id and just make it as my own temporarily, created the necessary certificates and provisioning profiles and then tested it using PushMeBaby app. All works fine without problems.
And now, the client wants to publish it and he gave me the distribution certificate and provisioning profile for distribution. I am not a member of his team but I somehow find a way to build it using the command line.
Now comes my problem, I wanted to test it first on my device to check if the push notification works. The server is already setup since it is already existing in the store. I know for sure that the push will work, but somehow I really feel the need to test it first on my device. I tried to request him to use testflight for testing but he said he doesn't know how to do it. I tried to present myself to do it but he doesn't allow it because the original developer made some anomalies with his account, so as much as possible, he won't give it to me saying there must be other way to test it myself.
And so I asked, is there any way to test it with just the distribution certificate and provisioning profile provided? If not, what would be the best alternative to do it, considering having the client do a very minimal and easy stuff on his side, if any.
Hoping for someone to actually give a hand or a hint.
Thanks in advance.
... or am I doing something wrong? (Yep. I was. Feel free to skip to the Update section.) I've read a couple of quickstart posts and was ready to dive into the "amazingly new language", so I visited https://developer.apple.com/swift/resources/ in order to get my hands on some nifty tutorials and what did I get? I downloaded a Lister XCode project, opened it, switched build target to My Mac, started the build and... all I got was a couple of windows telling me to become a developer for 99 bucks.
I'm pretty new to all this locked-in-itself Mac/OS X/whatever ecosystem and, coming here from mostly free and painful Linux, I find these little things really repulsive, so I hope that this problem is really in my head and I can run exemplary code without paying $99.
If this is an off-topic question, please point me in the right direction (except for the case when you think I should crawl into some dark corner and cry about how hard thing in real life are).
Update. This issue seems to have a happy ending. As some of you mentioned in the comment section and in your answers, I should've disable the code signing feature for the project in order to build and run it. The confusion was all mine when I did disable the signing procedure for the sub-projects that interested me (ListerOSX and its dependencies), but as it turned out, in order to successfully compile and launch the project, one also should disable signing for all the sub-projects (targets, whatever). E.g. if you are launching ListerOSX, make sure you've disabled signing for Lister Watch app etc.
Seeing as this was at least a bit subtle for me, of whom you might say 'Mac development newbie', I'd still ask you not to close the question but rather leave it open: should anyone else stumble into the same problem, my story might actually help.
Recent versions of Mac OS X will not allow software to run unless it is signed by a developer, or the user is technically savvy enough to bypass gatekeeper (which is not very hard. Just right click on the app and select "open", and then the unsigned software will run).
This is an attempt by Apple to block malware distribution. If malware is not signed, then users who are likely to fall for malware will not know how to make it run. If malware is signed, then Apple can can pass the signature (and associated contact details) to the FBI who will try to organise a lengthy jail term.
What this means for you, as a developer, is you need to either get a certificate or accept that your software will only run with gatekeeper turned off.
The normal mac developer program is $99/year and includes a whole bunch of stuff that makes it well worth the price. However there is a free "Developer ID" membership level that only gives you the ability to sign your apps.
So, you've got three options:
sign up for a free developer account and sign with that
sign up for a paid account
don't sign your code and accept that it will not pass gatekeeper. just disable code signing in your "release" builds. It's already disabled by default in "debug" builds.
Disable code signing via on all targets in the project settings. Code signing with an official Apple certificate requires a paid account. You can still sign your code to identify yourself as the author, but it will not pass Gatekeeper automatically and you will not be able to sign directly from Xcode.
I have made a simple desktop app that I want to sell through the AppStore. Of course I want to be protected against piracy. Does AppStore give any protection? How does that process work?
For instance, what prevents a dishonest person from buying my app and then upload it on a torrent and share it with others. If these other people download my app, will they automatically be asked for their identity check (Apple ID and password), the first time they try to use my app, thus preventing them from using it if they have not bought it legally.
If this identity check does not happen automatically, then do I need to add some code in my app that will ask for the identity check. If so, where can I find info about how to do that?
I'm not entirely sure how this process works. Could somebody shed some light on it?
Mac App Store slips a receipt each time it is downloaded into the bundle. The receipt contains information about the computer used (the so called GUID) and the user logged into the App Store.
See here how you should validate the receipt:
https://developer.apple.com/library/mac/releasenotes/General/ValidateAppStoreReceipt/Introduction.html#//apple_ref/doc/uid/TP40010573
If you implement the GUID validation as described in the document, the app will not run on any other computer.
Also check the signature of your code to make sure it has not been tampered:
Verifying app's signature by code
Your application, when downloaded from the App Store, contains a receipt. The receipt contains proof that it was downloaded onto this computer from the App Store, and the ID of the application. There are instructions somewhere on Apple's website that tell you how to verify the receipt and what to do if the verification fails.
That said, you are much better off concentrating on writing an app that people actually want to buy. People who pirate your app wouldn't hand over money if it couldn't be pirated. They would do without it, pick some free app, or pick a different app that they can pirate.
And I'm quite sure that any copy protection you build into your app yourself will get it rejected from the App Store.
Even though the answers I've got were helpful, they didn't quite provide the answer I needed. Looking around I found a software called Receigen from Laurent Etiemble, and the FAQ on his site (http://receigen.etiemble.com/faq.html) gave many answers for what I was looking for. For instance
What is an App Store receipt validation ? Why is it needed ?
Basically, an App Store receipt is what an application must check to ensure that the copy is genuine and can be run.
What happens if I don't check the App Store receipt ?
Well, anybody with a copy of your application can run it, with or without proper authorization.
Is the code receipt validation easy to write?
No because it requires deep understanding of cryptography and secure coding techniques.
It didn't hurt either that Receigen generated code that freed me from dealing with receipt validation code. Receigen takes care of this part so I can focus on what is really important for me: my application.
Yes, it costs money but personally I am more than glad to pay it, because I find this part of the development tedious, boring and complex.
TPInAppReceipt is a great package for this.
I was able to easily add local receipt validation after trying many others solutions less successfully:
https://github.com/tikhop/TPInAppReceipt
I hired a developer to develop a BB10 application for me. Now he has provided me a bar file signed with his own signing keys. Can I submit this application to App World using my account? Or I need to ask for the code and again sign the application. What is the criteria we need to match?
Thanks a bunch,
Apurv
I do not know if BlackBerry World checks keys assigned to developers against vendor accounts, I doubt that they do. However, if you submit an app signed with a particular key set, you will only be able to upgrade that application with a BAR file signed by the same key set. Does your contract include the developer providing you with source code? If you do an upgrade will you be using the same developer? The answers to these questions should help you decide.
I'm stuck with this damn "Application failed codesign verification" warning that I simply can't solve... I'm about to submit my app to Apple. :(
Having a look to my provisioning profiles made me realize that the status of my development profile is "Active, managed by Xcode" whereas my distribution profile is only "Active". It may be the reason of this problem because anything else seems to be OK. So what is wrong here ?
Thanks a lot for your advices.
Having a look to my provisioning profiles made me realize that the
status of my development profile is "Active, managed by Xcode" whereas
my distribution profile is only "Active".
The team development profile includes certificates for all the developers on your team and device ID's for all your devices. Since only one person is authorized to distribute applications for any given account, and since there are no device ID's associated with the distribution provision, there's no need to have Xcode or the provisioning portal manage your distribution provision -- there'd be very little to manage.
It may be the reason of this problem because anything else seems to be
OK. So what is wrong here?
No, difference in the description of your development and distribution profiles isn't the problem. The problem is that the codesign utility was, for some reason, unable to sign your application. There are several things that can prevent your app from being signed, such as:
Wrong distribution profile selected in your project's build settings.
App ID in distribution profile doesn't match that of the app you're trying to sign.
Problem with distribution profile, e.g. an expired certificate.
There are also a great many questions right here on SO pertaining to signing your app for distribution. It doesn't make sense to rehash all those answers here, especially without more information about what you've already checked or at least seeing the specific error. Take a look at some of those questions first and see if something rings a bell. Otherwise, take a look at the Troubleshooting section of the Tools Workflow Guide.