{"_id":"590a04f8ed80861900cbc7a9","category":{"_id":"590a04f3ed80861900cbc74c","__v":0,"version":"590a04f2ed80861900cbc737","project":"55b2d5baa74a380d00e290c4","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-01-05T19:32:59.974Z","from_sync":false,"order":22,"slug":"troubleshooting","title":"Troubleshooting"},"version":{"_id":"590a04f2ed80861900cbc737","project":"55b2d5baa74a380d00e290c4","__v":4,"createdAt":"2017-05-03T16:27:30.085Z","releaseDate":"2017-05-03T16:27:30.085Z","categories":["590a04f3ed80861900cbc738","590a04f3ed80861900cbc739","590a04f3ed80861900cbc73a","590a04f3ed80861900cbc73b","590a04f3ed80861900cbc73c","590a04f3ed80861900cbc73d","590a04f3ed80861900cbc73e","590a04f3ed80861900cbc73f","590a04f3ed80861900cbc740","590a04f3ed80861900cbc741","590a04f3ed80861900cbc742","590a04f3ed80861900cbc743","590a04f3ed80861900cbc744","590a04f3ed80861900cbc745","590a04f3ed80861900cbc746","590a04f3ed80861900cbc747","590a04f3ed80861900cbc748","590a04f3ed80861900cbc749","590a04f3ed80861900cbc74a","590a04f3ed80861900cbc74b","590a04f3ed80861900cbc74c","590a04f3ed80861900cbc74d","59124949de13f61900336a7a","5914b04e7c2c552d008b7104","5914b47242c6a22300b9dc20"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"7.0.0","version":"7"},"user":"55b2d5626862a10d00887af9","__v":0,"parentDoc":null,"project":"55b2d5baa74a380d00e290c4","updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-12-01T20:32:12.483Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":1,"body":"We’ve put together a quick checklist to help teams troubleshoot the most common causes for build failures.\n\nHere's what you can to do quickly diagnose and likely resolve build errors:\n\n* Rebuild without cache\n* Clone your repo and check if your app builds locally\n* Share your schemes\n* Ensure your tests pass\n* Double check your third party dependencies\n\n### Rebuild without cache\n\nCaching is one of many techniques used by buddybuild to speed up build times. However, some build failures can be caused by a corrupted or out-of-date cache. Rebuilding without cache is a quick way to evict the cache and rebuild from the most recent committed code.\n\nTo do this, select the build you’d like to rebuild, then navigate to the build’s “Details” and click “Rebuild without Cache”.\n\n<img src=\"https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/1.jpg\"> \n\n### Clone your repo and check if your app builds locally\n\nIt is important to make sure there are no discrepancies between your remote branch and local git state. \n\nBuddybuild creates a fresh clone of your code and executes build commands on every commit. \n\nHere's how to replicate this process and ensure your remote branch is up to date:\n\n* Clone your repo into a **new location / folder** on your machine\n* Double check that you’re building the same target and scheme as identified in buddybuild\n* Open Xcode from the new location and simply **⌘B** to build your app locally \n\nSimilarly, if you’re experiencing issues when using buddybuild to push to iTunes Connect (for TestFlight or AppStore deployments) make sure you can Archive and Export your build locally as well.\n\nIn Xcode you can do this by navigating to **Product > Archive** then select \"**Export...**\" and follow the onscreen instructions to finalize exporting. \n\n<img src=\"https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/8.png\">\n\n<img src=\"https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/9.png\">\n\nAnd finally, if your builds succeed locally but still fail on buddybuild, run the same  `xcodebuild` command from buddybuild on your Mac to make sure that there are no discrepancies.\n\n<img src=\"https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/3.jpg\"> \n\n### Share your schemes\nSharing your schemes ensures buddybuild uses the correct build configurations (like test targets) for your builds.\n\n<img src=\"https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/4.jpg\">\n\nTo share your scheme, open Xcode, select **Product > Scheme > Edit Scheme…** (or **⌘<**) and choose the checkbox associated with the schemes you’d like to share. \n\n**Note:** Make sure you commit and push the changes to your repo so buddybuild can use them.\n\n### Ensure your tests pass\n\nIf your app has tests, make sure they run successfully on your Mac or local machine. \n\n<img src=\"https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/5.jpg\"> \n\nIf your tests are failing locally because of a known issue and you still want to them to run in buddybuild, you can always opt to treat them as warnings. This way failed tests won’t cause your builds to fail. To do this go to your App Settings and enable the “Treat tests as warnings” option.\n\n<img src=\"https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/6.jpg\"> \n\n### Double check your third party dependencies\n\n#####CocoaPods\n\nOne of the most common causes of build failures is a Podfile.lock missing from your repo. When using CocoaPods, the Podfile.lock specifies the exact versions your app uses. Without the Podfile.lock, unexpected versions of CocoaPods might be used during `pod install` on a new repo. \n\nPlease double check the Podfile.lock is checked into your repo, as it oftentimes is in `.gitignore`.\n\nAlternatively, you can also check-in the entire Pods directory in your repo. Buddybuild will detect checked-in pods, automatically skip the pod install step, and use the Pods exactly as they’re setup locally.\n\nIn either case, run `pod install` locally, then commit and push the changes to your repo.\n\n#####Carthage\n\nMake sure you set the Carthage version you use locally matches the one specified in your app settings in buddybuild.\n\n<img src=\"https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/7.jpg\">\n\nAlso make sure that your `Cartfile` and your `Cartfile.resolved` are checked into your repo.\n\n###Contact buddybuild support\n\nIf you've followed the steps above and are still unable to find the cause of your build failure, please drop us a line via Intercom or at [support:::at:::buddybuild.com](mailto:support@buddybuild.com) - we’re here to help!","excerpt":"","slug":"ios-build-errors","type":"basic","title":"Common iOS build errors"}

Common iOS build errors


We’ve put together a quick checklist to help teams troubleshoot the most common causes for build failures. Here's what you can to do quickly diagnose and likely resolve build errors: * Rebuild without cache * Clone your repo and check if your app builds locally * Share your schemes * Ensure your tests pass * Double check your third party dependencies ### Rebuild without cache Caching is one of many techniques used by buddybuild to speed up build times. However, some build failures can be caused by a corrupted or out-of-date cache. Rebuilding without cache is a quick way to evict the cache and rebuild from the most recent committed code. To do this, select the build you’d like to rebuild, then navigate to the build’s “Details” and click “Rebuild without Cache”. <img src="https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/1.jpg"> ### Clone your repo and check if your app builds locally It is important to make sure there are no discrepancies between your remote branch and local git state. Buddybuild creates a fresh clone of your code and executes build commands on every commit. Here's how to replicate this process and ensure your remote branch is up to date: * Clone your repo into a **new location / folder** on your machine * Double check that you’re building the same target and scheme as identified in buddybuild * Open Xcode from the new location and simply **⌘B** to build your app locally Similarly, if you’re experiencing issues when using buddybuild to push to iTunes Connect (for TestFlight or AppStore deployments) make sure you can Archive and Export your build locally as well. In Xcode you can do this by navigating to **Product > Archive** then select "**Export...**" and follow the onscreen instructions to finalize exporting. <img src="https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/8.png"> <img src="https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/9.png"> And finally, if your builds succeed locally but still fail on buddybuild, run the same `xcodebuild` command from buddybuild on your Mac to make sure that there are no discrepancies. <img src="https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/3.jpg"> ### Share your schemes Sharing your schemes ensures buddybuild uses the correct build configurations (like test targets) for your builds. <img src="https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/4.jpg"> To share your scheme, open Xcode, select **Product > Scheme > Edit Scheme…** (or **⌘<**) and choose the checkbox associated with the schemes you’d like to share. **Note:** Make sure you commit and push the changes to your repo so buddybuild can use them. ### Ensure your tests pass If your app has tests, make sure they run successfully on your Mac or local machine. <img src="https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/5.jpg"> If your tests are failing locally because of a known issue and you still want to them to run in buddybuild, you can always opt to treat them as warnings. This way failed tests won’t cause your builds to fail. To do this go to your App Settings and enable the “Treat tests as warnings” option. <img src="https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/6.jpg"> ### Double check your third party dependencies #####CocoaPods One of the most common causes of build failures is a Podfile.lock missing from your repo. When using CocoaPods, the Podfile.lock specifies the exact versions your app uses. Without the Podfile.lock, unexpected versions of CocoaPods might be used during `pod install` on a new repo. Please double check the Podfile.lock is checked into your repo, as it oftentimes is in `.gitignore`. Alternatively, you can also check-in the entire Pods directory in your repo. Buddybuild will detect checked-in pods, automatically skip the pod install step, and use the Pods exactly as they’re setup locally. In either case, run `pod install` locally, then commit and push the changes to your repo. #####Carthage Make sure you set the Carthage version you use locally matches the one specified in your app settings in buddybuild. <img src="https://s3-us-west-2.amazonaws.com/www.buddybuild.com/blog/engineering/iOS+Troubleshooting+Guide/7.jpg"> Also make sure that your `Cartfile` and your `Cartfile.resolved` are checked into your repo. ###Contact buddybuild support If you've followed the steps above and are still unable to find the cause of your build failure, please drop us a line via Intercom or at [support@buddybuild.com](mailto:support@buddybuild.com) - we’re here to help!