I haven't really used the archive function under Xcode 3, but got used to it now in Xcode 4. So far I always used to have three or four build settings in all my projects: Debug, Distribution AdHoc and Distribution AppStore. Distr. AdHoc and AppStore were both copies of "Release" and only differed in regard to their provisioning profile selected for Codesigning (so essentially they were a thing of convenience, making sure I never sent the wrong person the wrongly signed build).
Now I noticed that Xcode asks me with which profile I would like to sign my build with whenever I export an archived build form the organizer, yet at the same time the build would also fail if the selected provisioning profile in the build settings was not valid. Are Xcode 4 archives provisioning profile independent from or are thy tied to a provisioning profile? How do you solve the "challenge" of having to build for AdHoc and AppStore without having too many build settings groups (switching the groups associated with the build schemes has become somewhat cumbersome in Xcode 4)?
Thanks!
in Xcode 4 if you archive an application it is signed with the provision profile that you have indicated to use under its build configuration. Most likely a settings that was carried over from an Xcode 3 project.
An archived app can be resigned with a different provision profile at a later time (though the organizer or command line), so in a way, yes they are independent of provision profile.
Two suggestions for managing building for AdHoc and AppStore:
1)
The first is taking advantage of Xcode 4 schemes, and creating a new schemes for AdHoc and AppStore
Under the Schemes Menu: Edit Scheme -> Duplicate Scheme, then under the Archive you can select your desired build configuration (AdHoc, AppStore, etc...), you can then name this scheme AdHoc, AppStore to match too. When you want to build for release just select the target scheme and it will sign it with the associated provision profile from the build configuration.
2)
Maintain 1 scheme, remove code signing from your build configurations, and code sign apps exclusively though the organizer after archiving.
Related
I have JAR application ready.
i have apple account also. Please give me steps to signed app upload
Distribute apps in the MACOS App Store
This is the general workflow for publishing an app to the App Store using App Store Connect:
Step 1: Choose your build:
Each app can have multiple versions, and each version can have multiple builds. To publish your app on the App Store, choose which build to submit to review.
Step 2: Set pricing and availability:
You must set a price and set a tax category for your app. Although your app is available in all App Stores and localizations by default, you can select specific regions for your app instead. You also have the option to publish your app as a pre-order.
Step 3: Submit your app for review:
You submit your app for review to start the App Review process and to make your app available on the App Store. Before you submit an app, enter all the required metadata and choose if you want to release your app manually or automatically, or if you want to release your app in phases.
Step 4: Request promo codes:
After your app is approved, you can request promo codes to distribute to users before you make your app available on the App Store. You can distribute the promo codes by email or other means, and the user enters the promo code when purchasing the app.
Step 5: View your app status and resolve review issues:
After you submit the app, the app status changes to Waiting for Review. If there are any issues with your app, read and reply to App Review communications. After your app is approved, it can take up to 24 hours to go live on the App Store.
Outside the Mac App Store
While the Mac App Store is the safest place for users to get software for their Mac, you may choose to distribute your Mac apps in other ways. Gatekeeper on macOS helps protect users from downloading and installing malicious software by checking for a Developer ID certificate. Make sure to test your apps with the latest version of macOS and sign your apps, plug-ins, or installer packages to let Gatekeeper know they’re safe to install.
In the comments there are a few useful links (reputation doesn't allowed me to put them here). ;-)
Amplify does not support CLI option --profile. It always uses profile specified when application was generated. Different team members use different AWS profiles.
How to change/configure/use profile different than profile used during application generation?
Aim is to publish changes from different computer. Final goal is to use CI server to publish application to different regions.
Amplify does not work like "other" development tools where tool is detached from git. Amplify goes hand in hand with Git and requires initialization after cloning. Running amplify init and choosing existing environment (which is pushed by other developer), it is possible to select different AWS profile.
Xcode archives successfully using the latest - and correct - provisioning profile.
However, the Bots configured in Xcode Server still use an older profile.
This can be seen if one authenticates as xcodeserver user and navigates to ~/Library/MobileDevice/Provisioning Profiles.
Running security cms -D -i myuuid.mobileprovision confirms this.
Having tried reconfiguring a new Bot, restarting Xcode Server, deleting the old profile, and so on, nothing works.
How can we help Xcode 9 Server do what it promised, and use the latest provisioning profile from the Apple Provisioning Portal?
A dirty hack will work. This is assuming Xcode will correctly Archive using the correct profile. Unarchived the resulting .app file, then rename the embedded.mobileprovision file according to it's UUID, e.g.
myuuid.mobileprovision
Next, copy myuuid.mobileprovision to the ~/Library/MobileDevice/Provisioning Profiles folder.
Identify any older profiles linked to the same bundle identifier and delete. To play it safe, consider moving temporarily to ~/Desktop.
Finally, integrate the Bot, unarchive the resulting .app., and inspect to confirm creation expiry date, UUID, and UDID array are all as expected:
security cms -D -i embedded.mobileprovision
I am working on a ASP.net MVC4 project where a same project needs to be deployed to many clients on daily basis, each client will have its own domain / sub domain and a separate app pool and db (MSSSQL).
Doing each deployment manually could take at least 1-2 hours if everything goes well. Is there anyway using which I can do this in some automated way?
Moreover, we also need to update all of the apps when a new version is released.. may be one by one or all of them at same time. However, doing this manually could take weeks and once we have more clients then it will not possible doing this update manually.
The update involves, suspending app for some time, taking a full backup of files and db, update application code/ files in app folder, upgrade db with a script and then start app, doing some diagnosis script to check if update was successful or not, if not we need to check what went wrong?
How can we automate this updates? Any idea would be great on how to approach this issue.
As a developer for BuildMaster, I can say that this scenario, known as the "Core Version" pattern, is a common one. If you're OK with a paid solution, you can setup your deployment plans within the tool that do exactly what you described.
As a more concrete example, we experience this exact situation in a slightly different way. BuildMaster has a set of 60+ extensions that rely on a specific SDK version. In our recent 4.0 release, we had to re-deploy every extension because of breaking API changes within the SDK. This is essentially equivalent to having a bunch of customers and deploying to them all at once. We have set up our deployment plans such that any time we create a new release of the SDK application, we have the option to set a variable that says to build every extension that relies on the SDK:
In BuildMaster, the idea is to promote a build (i.e. an immutable object that travels through various environments like Dev, Test, Staging, Prod) to its final environment (where it becomes the deployed build for the release). In your case, this would be pushing your MVC application to its final environment, and that would then trigger the deployments of all dependent applications (i.e. your customers' instances of your application). For our SDK, the plan looks like this:
For your scenario, you would only need the single action, "Promote Build". As I mentioned before, any dependents would then be promoted to their final environments, so all your customer deployments would kick off once that action is run during deployment. As an example, our Azure extension's deployment plan for its final environment looks like this (internal URLs redacted):
You may have noticed that these plans are marked "Shared", which means every extension we have has the exact same deployment plan, but utilizes different variables to handle the minor differences like names, paths, etc.
Since this is such an enormous topic I could go on for ages, but I think that should be sufficient for your use-case if you wanted to try it out.
There are others but you could setup Team Server Foundation to deploy automated builds.
http://msdn.microsoft.com/en-us/library/ff650529.aspx
I find the easiest way to do this from an MVC project is to create a publish profile.
This is done by right-clicking your project selecting publish and then configuring it to your needs.
Then from TFS you create a new build definition, this kicks of a wizard which takes you through it.
There are quite a few options which would be too long to go into for every scenario.
The main change I usually find the most important is to set an MSBuild Argument to deploy with the publish profile.
This can be found at Process > Advanced > MSBuild Arguments.
Once this is configured correctly it's a simple case of right-clicking and queue new build to build and deploy.
You wil need different PublishProfile/Build configuration per deployment environment.
For backups I use a powershell script which can be called manually or from TFS.
You also have a drop folder in TFS which keeps a backup of x many releases.
The datbases are automatically configured via Sql server to backup, TBH I didn't set that up it was a DB admin guy who is also involved with releases.
From a dev testing side I use jMeter (http://jmeter.apache.org/) to run some automated scripts that check that users can login and view certain screens, just to confirm nothing major has gone wrong. However there is usually a testing team to run more detailed tests, again not setup by me.
All of the above will probably take you sometime to setup but in the long run it will literally save you weeks of time over a year.
A free alternative to TFS is http://www.cruisecontrolnet.org/, I have used this in the past too and is pretty good.
You can automate your .Net deployments with Beanstalk, which will give you a way to trigger deployments with a single click, watch progress, manage permissions and see history of deployments. Check out this guide on the topic:
http://guides.beanstalkapp.com/deployments/deploy-dotnet.html
I hope you will find it useful.
P.S. - I work at Beanstalk.
My client wants to submit the project by himself so he asked me to get the xcode xcarchive of the project and send him to sign it and upload it.
He gave me his development certificate, I installed it and sign the target with its provision profile.
The build configuration that I'm using for signing is a copy of "Release".
Now when he tries to resign the archive and submit it, iTunes throw an error Invalid Binary and the culprit is the Signature
Its says :
Invalid Signature - Make sure you have signed your application with a
distribution certificate, not an ad hoc certificate or a development
certificate. Verify that the code signing settings in Xcode are
correct at the target level (which override any values at the project
level). Additionally, make sure the bundle you are uploading was built
using a Release target in Xcode, not a Simulator target. If you are
certain your code signing settings are correct, choose "Clean All" in
Xcode, delete the "build" directory in the Finder, and rebuild your
release target. Once you have corrected these issues, go to the app's
version details page (found in the Manage Your Applications module of
iTunes Connect) and click Ready to Submit Binary. Proceed through the
submission process until the app's status is Waiting for Upload. You
can then use Application Loader to upload the corrected binary.
Do I need the private key used by my client?
Can someone please point me to the right direction? Can I get any tutorial or video how to resign the archive and submit it to the store.
I think you should ask your client to generate a distribution certificate and then sign your project with it.