Yep, back at you and @Meltdown…I’ll say that any prior iOS work is a huge benefit, and I can tell you from the days of iOS 2.x programming that Unity and Xcode have come a long way in removing tedious project tweaking on the Xcode side of things. I don’t have my dev MBP at hand, so what I’ll rattle off here is from memory…and feel free to hit me up directly if you want to take any of this outside the forum thread…but for now, here goes the shotgun response:
First stop and required reading: Unity - Manual: Getting started with iOS << lots of good info there, everything from optimizations to specific build questions to links on setting up the core cert / profile jazz you need from Apple. The only flaw I see so far there is that they note Terrains are not supported on iOS…which was a 3.4 release feature.
As far as personal experience goes, right now (and at the risk of horribly jinxing myself lol) I have zero build issues from Unity to Xcode to Device…just build the player and bam, up and running on my iPhone. Where things typically fall apart is on the Xcode side of the pipeline…your project compiles fine in Unity but fails to build / deploy in Xcode. First thing to remember is the wealth of knowledge here on the forums and in UnityAnswers. Example, search either for “Base SDK missing” 
…which brings me to my first tip: Unity version upgrades mid-project usually no problems…Xcode version updates mid-project not so much unless you’re managing multiple versions / using virtual environments etc. Case in point, here is a note straight off the 3.4 blog release:
The other typical build-stopper in Xcode will be expired provisioning profiles and/or identity certificates. Your choices there (on the Apple Developer portal) are to manage those objects yourself, or to have Xcode’s Organizer / shims interface with the portal and do it for you. I personally prefer the former, but my advice there would be to not mix the two. You should be aware of the Keychain app on the build machine, and understand how to check for valid certs there.
For more ‘involved’ problems, the troubleshooting page for iOS as referenced is here and has excellent pointers and also a basic guide on how to use the native Xcode tools in profiling your application. Ergo, next tip: learn how to use Xcode / Instruments directly with your project after Unity has built it. While Unity Pro has its own profiling built in, for iPhone Basic there is plenty of functionality in Instruments and watching the internal profiler’s output in the Xcode console that is critical to understanding where your bottlenecks are at runtime. AppController.mm is of note in the Xcode project, and is where you’ll find many lower-level flags along the lines of the profiler.
Other tips, in no particular order:
- Learn to watch the Console windows…in Unity as well as Xcode. A ‘big’ one that often can float by unnoticed in the Xcode console is applicationDidReceiveMemoryWarning…
- Debug.Log(“Test whatever”); statements, while useful for lightweight editor debugging, are framerate killers if you push that out to a device
- Read the Editor Log in Unity to understand how and what Unity is putting together to hand off to Xcode
- Don’t be afraid to give Xcode an enema if a working build suddenly starts tanking on you – Clean Project, and under the main toolbar menu, Empty Caches
- Try to avoid having to rename projects and AppID’s
Anyhow, I’m about off my lunch break and gotta get back to the regular grind. Good luck with everything, and hope some of this is useful!
