Apphance ServiceNot all IOS projects can be build in CI system immediately. Mostly projects for iOS are created using XCode, and developers don't really check if project can be built automatically. This is especially important if you have complex, enterprise grade project, which contain many libraries, dependencies etc.
There are a few easy steps that you can follow in order to make your project CI-enabled.
In case of more complex projects, the applications are split into smaller libraries. The only officially recommended way of doing that was referring to software libraries source rather than using binary artifacts. Officially XCode does not support another way of sharing code. There are several projects that aim to fix it and are widely used (Cocoapods is the most prominent one ). Apphance Flow will support Cocoapods in one of the upcoming releases. Until then, simply make sure that all the library source code is added to your projects and checks out together with the application's code. You can used shared code using mechanisms described below (in version-control system dependent way).
Here are some best practices that you can follow in order to get your project prepared for automated checkout:
1) Keep your project and libraries as separate repositories (in case of modern distributed version control systems like git or mercurial), or as separate paths (in SVN).
2) Link the libraries using mechanisms provided by the respective version control system. This is provided by mechanism like "svn:externals" in SVN, "submodules" in git, "subrepository" in mercurial. Other VCS system have similar mechanisms. Usually such mechanism works transitively, so you can have libraries linked to other libraries. The nice feature of those mechanisms is that you can link to either fixed version of the library (if you require stable link) or you can link to a HEAD of any branch or master of the library in case you have a library which is under heavy development and you want to take advantage of frequently switching to latest version.
3) When you checkout the project follow the VCS's instructions on how to checkout the whole project with all the linked repositories (Follow the links above if unsure).
In Apphance Flow we make extensive use of schemes, and as a developer - you should use them to. More often than not you are supposed to build several different variants of your application - be it production/AppStore version, development version talking to your development servers rather than to production ones, or test versions which has a test version of bug reporting tool (like Apphance) used. Rather than changing the targets and configurations manually, you can (and should) have scheme defined for each and every variant of the application that you would like to use. The schemes need to be shared (mark it as such in the XCode project), because that's the only way to tell CI server what configuration should be used when building the application. You can configure pretty much everything in the schemes defined per each application variant. Things like basic preprocessor macros per configurations are obvious, but not everyone knows that even things like different application names, bundle ids, icons can be configured per variant - by using different Info.plists in each variant.
At the end what you want to have is whatever the variant of the application you have, you should have a scheme defined that you should simply switch to. Avoid changing configuration or some preprocessor macros manually in your project just to achieve a different variant - if you need a different variant, configure it as scheme.
Again. Before you start with Apphance Flow, you need to have shared Schemes defined in your application.
Certificates are needed in order to build the application. More of that is described in separate section: iOS certificates - check that the certificate is properly imported at your server and that you've build the project once and chose "allow all".
Each of the projects can be configured to add Apphance automatically - separately for each scheme/variant. This is great help in case you want to produce different builds - some with Apphance QA and some with Apphance Prod libraries and configured differently. Apphance Flow allows to configure each variant to add Apphance automatically and even to send the build to Apphance automatically after every release. More about this in Apphance Service.
You can follow from here to Add Flow to iOS project