I need to know how to allow 2 Macs to work on the same project.
Currently the app is in the app-store and only 1 mac is working on the app.
I want to add a new developer, i.e. new mac, to the project.
Please provide me with a simple, step by step, instructions I need to do in order to make this work (regarding certificate, key-chain, bundle, etc).
P.S.The app uses push-notifications as well, does a new mac will damage the push notification mechanism?
I came across Developing iPhone app on multiple Macs, it didn't really answer my question. I want to know, from Apple perspective, what do I need to do in the new mac in order to build the exact same executable from both machines. (and not harm the current push mechanism).
Thanks...
There is a tool called version control. You could use git or SVN or Mercurial.
When compiling (with your company Apple Developer account) your code will be identical on both Mac (if you updated on both sides). Actually, my own code is indifferently compiled on my iMac, my Mac Book Air or my girlfriend's Mac Book Pro.
Make sure the 2nd Mac has the same iOS Development tools and SDK installed. Export your Developer and Distribution certificates from the first Mac. Create a new User account on the 2nd Mac and install the certificates there. Copy your project and all source files ( including the app's plist, xibs, resources, etc.) to the 2nd Mac (or, if you are using a version control repository, check out a fresh copy of the desired revision).
Push notification have nothing to do with the Mac used for building an app. If the 1st Mac is acting as the push notification server, it can still do so for apps built on the 2nd (as long as you don't change any IDs, etc.)
versioning :) http://en.wikipedia.org/wiki/Revision_control
basically, you have a common box where to store your in-developement files (called "repository")
this repository has some features like version rollbacking, conflict and modifies tracking, bug tracking and so on...
the idea is simple: you have your files and your online repository, you add those files to your repo. i then join the project and grab those files (operation is called "checkout"), modify a bunch of them and i perform an operation called commit: this operation checks my version merge the modified files with the one online. You then "update" your local version: if you didn't modify the same lines i did, there's no error and you succesfully update. If we modified the same line, and there's conflict, the update process breaks. You can then see where the error appears, and resolve it with a diff tool (http://en.wikipedia.org/wiki/Diff)
Pretty easy as concept, pretty fundamental for us developer. You can have how many people working on the same project without problems. You can work on separate bits of code without the need of the other. You can work on the same file without generating conflicts.
Google hosting and Sourceforge are two great example of repositories (you may also want to check out Git which a little bit different)
so, briefly: SVN is the answer you need :)
Related
How can we make the flutter app to make automatic update whenever we release a new version of the app into the store. but I don't want to use the pop up to alert the user to update I want to update automatically without letting the user even know we update it.
As said in the comment, if you publish to Google Playstore or iOs AppStore, they will handle the updates for you. You just have to upload the new version (just set the release number correctly) and, when the validation is done, their system will notify/update the app. I don't know how other stores behave, but I'm guessing that's the standard behaviour now.
Instead, if you need to bypass the store functionality and perform the update "by yourself", I don't think that is gonna be a simple task. Apple simply doesn't allow installation from other sources than their store, so I fear it may be simply impossible. On Android, on the other hand, I know that's possible, but it will require some user interaction beforehand, since the "installation from unknown source" authorization must be provided to the app that downloads/opens your .apk file, and the procedure may vary from a device to another, so I fear there won't be a single mechanism that will work everywhere.
In any case, the base mechanism will probably require some HTTP GET by your app towards some webserver that will reply with the latest version: the app should then compare the received version number with its own, and then proceed to the download of the package (the URL for the download can be provided along with the latest version number). After that, you have to manage somehow to install/update the downloaded file.
I personally used this approach with Flutter on Windows 7 and newer, where there are no store constraints and I can simply run and download the .msi or .exe file for the latest version, and works just fine.
I think you are looking for the concept of codepush which was loved by many React Native developers.
In Flutter, I think you might want to check out flutter_code_push if this fits your needs.
I have followed the steps given in http://developer.samsung.com/tv/develop/legacy-platform-library/art00121/index, and the application appears on the Smart Hub on the TV. However, when I make some changes in the application, and package it again selecting "Update the packaged files on the server", do a "Apps Sync" and run the application, the updates are not reflected.
I have tried changing the application name and version in config.xml. Only the application name changes in smart hub, but the application when opened is what was installed the first time on the TV.
If a new project is made and the same steps are followed, the new application appears on the smart hub, but an update to it has the same problem.
Am I missing something while packaging the same application for a second time?
Not sure if this is useful but I believe the device seems to cache the files. I had the same issue today and was quite frustrating.
I managed to find two solutions:
1) shut down the device and re-launch again (connect to server and the Apps Sync)
2) when you export the app in the IDE, make sure you name the package name differently + title & description need to be different too.
By doing this, Apps Sync will add another app (so you'll have two of the same app, but just click on the last one that appears in the apps list - hope that makes sense). If you want to remove the apps, simply access the widgetlist.xml which will be in the root of your server and then remove the apps references from there.
I hope that helps.
I have an xcode project that has 4 targets (2 apps, 1 iPhone and 1 iPad version for each). I have recently implemented Core Data Lightweight Migration.
I am currently only testing two of the apps, the iPhone versions, call them App A and App B. I am able to run the current app store version of App A on my iPhone, then install my new version of App A to test the Lightweight Migration. It works fine, no problem.
Then, I try the same thing with App B. I am able to install the current app store version of App B on my iPhone no problem. BUT, when I try in install the new version of app B on my iPhone, I get the following error (or a variant of it) EVERY time: "putpkt: write failed, broken pipe"
I am confused since the two current versions are in the same project and have the exact same settings for every configuration (debug, release, distribution). The is not ad-hoc distribution.
Every post I have read for this error on this forum, and anywhere, suggests things like removing the app, restarting the device, restarting xcode, etc. And sure, I can get it to work that way. BUT I cannot test my migration that way.. If I remove the old version of the app from the device nothing is getting migrated!
I am pulling my hair out over this. The two apps were originally in two different projects, and I added App B to the App A project as a new target - that is the only thing I can think of, as I feel like I have looked at everything. I would really appreciate some help to figure out this problem. I feel sick about sending out a database update that I cannot test - I can't take the chance of corrupting people's data, especially when I have not offered a backup option until this current version. Ugh.
EDIT: when I try to run App B on the device without updating, I often get the following error:
Error Starting Executable... Don't know how to run. Try "help target".
EDIT: I think I am having this trouble because I renamed the product name for app B. I think this changed the bundle and will not allow me to migrate data. I will try to change it back and post an update. It seems like merge bundles IS working well for app A in the meantime.
Making sure the new project and the original project had the same product name and the same data model name fixed this problem for me.
I was just making a free version of one of my apps. I copied the folder, renamed the project, and changed the icon file, loading screen, interface, and code. BUT YET it still replaces a build on my phone.
1)how do I stop this from happening (i want both the free and paid version on my phone)
2) if you can fix this, will a customer who has the paid, and downloads the free, will that replace it on their phone?
I really need to know these, as I have the app ready to go, and would like to get it before the end of the week.
cheers
Sam
You need to have a different app bundle identifier. I think that's your problem.
Long answer:
Go into your projectname-info.plist file and change the CFBundleIdentifier.
I'd recommend something like:
com.mycompany.mycoolapp for the app store
com.mycompany.mycoolapp-beta for the beta version
You should actually be able to set up the "Debug" build configuration to use a different info.plist file configured with a different CFBundleIdentifier and a different icon filename. That way you'll automaticlly get the beta ID and icon, etc for the Debug build and the real id/icon for the full one.
This should allow users to install and use both the production and test versions of the apps at the same time without confusion.
You might also find this IPA target template helpful if you're doing ad-hoc distribution to Windows users for testing:
http://devblog.appmagination.com/2010/01/target-template-for-building-iphone-ipa.html
I found this previous question about Cocoa projects, but I wanted to know if it's the same for iPhone projects.
As far as I know, the same responses there apply to iPhone development as well. In my projects, the only files I keep under SVN's control are the source files, any resources (images, .XIBs, audio, etc.), and the .xcodeproj file.
It may be a good idea to version control provisioning profiles. Especially for an ad-hoc beta test profile, you'll need to update it every time you add a new beta tester, and having a history of that seems like a good idea.
Actually there is something I would say you should version control that you would normally not - the final application bundle and dsym file, both under build. However, you only need to archive these when you release either an ad-hoc or distribution build for the store - so I'd leave build in the ignore file, but have somewhere you can copy these files to check them in for a distribution and tag them along with the source.
You'll probably want to compress the app bundle before placing it in this save directory
You need these two files in order to be able to symbolicate crash logs sent to you by either beta testers, or users of the app from the app store. A meaningful stack trace of a crash is priceless!
If you're planning on updating the app over time in addition to project sources and media you may also want to put the following under version control:
Signing certificates for app (and/or mobileprovision files).
The final version of the binary app (zipped) submitted to Appstore.
Binary.dSYM file for each revision (for post-release crash symbolicating).
Screenshots/icons/text file of description for app as submitted to Appstore.
Before beta releases you may also want to put mobileprovision files as well as a snapshot of the device list from the Developer portal for that version just so you can go back in time and figure out who got what release. If you're really hardcore you can also keep emails submitted by beta testers so you can keep it all in one place and go back and double-check against bug reports.
Yes. I use the exact same .gitignore file for iPhone OS projects as I do for Mac OS projects.