I am using Xcode 9.4 and current react native version #0.54.4 I want to upgrade the version to 0.55.4.
As I upgrade my project using react-native-git-upgrade, I see some un merged conflicts in the project.pbxproj. Some of the settings are my own that are conflicting with the changes in the new version.
I tried all the possible ways in which I could resolve the conflicts. But still X-code shows the error could not load the project, and it does not allow me to build my project.
How do I understand what those conflicts are referring to and how can I safely resolve the conflicts?
Unfortunately there is no magic way to resolve conflicts. I wish there was. The file is managed by Xcode and from personal experience I have found that you can easily mess it up performing merges.
Git is definitely your best-friend. Make sure that before you start any merge you are on a new branch and fully committed so that if you mess-up you can easily get back to your original version.
What I usually do is keep the original version of the project.pbxproj and then make the changes manually in Xcode. I know this doesn't sound ideal but it does mean you should be able to open the project in Xcode, though your project may not run - just yet.
If you’re unclear about which version to keep, I would keep ours as that is the original version of your project.pbxproj. From the documentation:
You can think of "ours" as "your team" and "theirs" as "the React Native dev team".
Then I would make the changes manually as detailed below. As that will show their changes and the should hopefully not be that many.
To help me find the changes that I have to make I find that React Native Upgrade Helper is an invaluable resource. There you can find a git diff of any two versions of react-native that you choose. (This saves you having to create two projects and then compare them yourself, a big timesaver.)
Currently you are upgrading from 0.54.4 to 0.55.4 this link shows the diff between those versions
https://react-native-community.github.io/upgrade-helper/?from=0.54.4&to=0.55.4
For additional help you could create a project in a specific react-native version, using the following will create a project for version 0.55.4.
react-native init newproject --version react-native#0.55.4
That way you can look inside the Xcode project to see what has been added, and where it was added from, as the git diff doesn't always tell where it came from.
I have never had much luck using react-native-git-upgrade and I have come to prefer doing it manually, as I have had much more success doing it that way.
After updating react native to version 0.55 from 0.51, everything seemed to function normally in the local mode. But the production build fails.
I fixed this by upgrading react native once again from 0.51, and keeping my changes instead of theirs almost all the time.
May be there should be more detailed explanation in the documentation regarding the kind of issues one run into, by picking the wrong changes.
Related
I have a Xcode project I got from another developer. Initially when I opened it it has a bunch of errors (most of which were un-updated frameworks). I got it to work after a while and I fixed it. I want pass it back to the manager since I'm leaving uni in a few months. I copied it over to my friends Mac to see what would happen if I just took the project and all it's folders and made it a zipfile. It didn't work for some reason. It gave me an error:
error: using bridging headers with framework targets is unsupported
But why did that come up? I mean it's the same code on the slightly different versions of Xcode (13.1 versos 14.1) but I doubt there was a massive change between the two that would cause this. I want to be able to pass these app later in the future without having to care about this stuff. I made a GitHub (link below) would cloning that work? Also the laptop I chose was just a fresh reset. Would it be due to not having coco-pods installed?
I feel like I could go through and fix it all on that laptop and document that but then I'm afraid that every time I put it on a new one it would come up with random errors every single time making my documentation moot.
https://github.com/AbdullahMSaid/SonicExperiment-Works
With big help this was Fixed.
Things that fixed it.
Having the correct version of Xcode
Turning everything from absolute path to relative
Lots of other code fixes. But those are my project specific.
You don't need bridging headers in framework. Use should have something like "YourFramework.h" where you can import your .h files.
I'm following the React-Native documentation for building iOS for production, located here:
https://facebook.github.io/react-native/docs/running-on-device.html#building-your-app-for-production
I find these instructions very strange, because it tells you to manually edit files and xcode settings. It seems extremely annoying and error-prone having to do this every time you want to create a new release.
Is there a reasonable way to automate this or use some kind of conditional for dev/prod?
I have a project which is almost completed in swift 2.2, Now I want to update the code to swift 2.2 to swift 3.0.I am using the Cocoapods for thrid party library integration and need following suggestions:
Should I go ahead update the libraries used first by running pod update? If any lib has not updated to support swift 3 what should i do?
Should I go ahead to update code to swift 3 manually or follow the XCode8 suggestions?
If I directly go for XCode8 suggestions then XCode8 starts giving suggestions to update library source code also.I am searching for the good way to handle all this. Thanks.
There is not a "best" way — as every project is potentially different in how easily it can be converted to an updated version of the language it's written in.
It would be recommended to:
Save a backup copy of the project before attempting to convert/migrate anything.
Follow the Xcode recommendations for updating the code.
Update the dependencies such as Cocoa Pods.
Fix any unresolved issues that might not have worked during the conversion.
Have patience, as often the conversion is not a one-click process.
If some of your libraries haven't been updated to Swift 3.0 then that's no problem, as you can tell the compiler to compiler only that library with the old compiler.
My suggestion, (and indeed how I updated my own projects), is to run the automatic migration wizard. (Editor>Code Syntax>Upgrade to latest Swift syntax). Then you should run pod update making sure to remove any version specifiers in your podfile.
Once you have done both of these things you can open your project and be greeted with a lot of compiler errors, the bigger your project the more you will have; unfortunately this is somewhat unavoidable because the built in migration tool sucks.
Now it is going to be a case of trudging through and fixing these errors, most of them will probably be something really simple like dropping AnyObject for Any, but a few may trip you up.
Now as I mentioned, if a library hasn't yet been updated for Swift 3.0 you can open your Pods project settings and select the library in question. Under build settings you'll find a key called Use legacy Swift syntax. Set this to true and rebuild. This forces the compiler to use the old compiler for this pod only.
I hope this in depth explanation is of help.
I Found some strategy migrating to Swift 3
I migrated directly to Swift 3.0. I use CocoaPods, so I migrated my dependencies first. This means following the steps above for each open source library (or private pod).
So far, the only dependencies I have for this project are my own libraries, which made this quite easy since I control all of the code. However, if you have third-party dependencies, then I would recommend opening an issue on the project to discuss migration plans with the current maintainers. I expect most popular projects are doing something similar to what I described above. For example, AlamoFire has a swift2.3 and swift3.0 branch. If needed, you can fork and migrate third-party libraries yourself — then submit a pull request or use your fork until the maintainers offer a solution. However, you should definitely reach out to project maintainers before submitting a pull request for migration.
Until Xcode 8 is final, you’ll need to point your pods to these new branches:
pod 'MyLibrary', :git => 'https://github.com/username/MyLibrary.git', :branch => 'swift3.0'
This tells CocoaPods to fetch the latest on the swift3.0 branch, instead of the latest published version.
Once your dependencies and Podfile are updated, you can run pod update to bring in the Swift 3.0 versions of each library. Then you can migrate your main app. I suggest commiting all of this migration in a single commit — update all dependencies, migrate your app, then commit — to keep your history clean.
Bugs
Xcode’s migration tool is not perfect.It would sometimes fail to migrate test targets, or only partially migrate app and framework targets. When this happens, you can attempt to run the tool again, but it’s probably best to make changes manually. Here are some of the specific issues that I saw:
Some expressions inside of XCTAssert*() did not migrate.
Some expressions inside closures did not migrate.
Sometimes waitForExpectations(timeout:) did not migrate.
Migrating NSIndexPath to IndexPath when used in certain contexts often resulted in derpy things like (indexPath as! NSIndexPath).section.
Enums with associated NSDate values migrated to case myCase(Foundation.Date) instead of case myCase(Date).
Sometimes optional protocol methods did not migrate, which can produce hard-to-find bugs.
Ref Links :
http://www.jessesquires.com/migrating-to-swift-3/
https://swift.org/migration-guide/
I am currently building an iOS app written in Objective-C and Swift containing the openssl and openldap frameworks, which builds and runs without any issues.
However, when I try to archive the app for release, the below errors occur:
Here is some additional information:
The Xcode version is 7.3.1 (7D1014)
The project is an Xcworkspace (contains a podfile, but the frameworks are not integrated through Cocoapods)
UPDATE:
After further testing, another makefile error occurred (similar issue in any case)
This image illustrates all the frameworks and libraries used and the errors that occur.
Here is the build log:
I appreciate any assistance and would be happy to provide any additional information.
Note: I am still looking for answers in order to solve this issue
I'd actually recommend something completely different. Making opens and openldap as standalone universal static libraries that you just link to. Presumably, this is what Makefile-openssl and Makefile-openldap are doing (making the universal lib)
"Why would I do such craziness?" you may be thinking. The code for openssl and openldap are not changing ... unless you have a unique case where you have forked the code and have some modification (which would probably be a bad thing). Thus there is no need to continually re-build it.
"Ahh but what about if I want to update the version?" you may be thinking. Then get the latest source and build it once. Done.
The benefits are that you are not wasting time building those libraries. While you could say it is not big deal right now, as projects get bigger, you're just wasting time re-building libraries that are not in active development. Additionally, you don't have to worry about any weird build issue like this.
For some projects I've been working on, I've convinced them to even make a pre-built library of all the cocoa pods libs we need in the project. Which has had the added benefit of keeping our main project a bit cleaner of the pods nastiness (I know some people will disagree) in your project.
Every time I meteor build, I have to open XCode and do the following:
remove and add an item from "Link Binary With Libraries" (Facebook SDK)
add a URL Type (custom URL scheme for my app)
add a "Required device capabilities" to "Custom iOS Target Properties"
How can I edit my Meteor project to have these steps done automatically, and to auto add things to AndroidManifest.xml?
In some way use mobile-config.js or cordova-build-override?
I'm happy to see another guy who is trying to build a hybrid application using Meteor / extending a Meteor Cordova iOS app, since I'm facing the very same issues. So I'm very happy to share my experiences and approaches with you. :-)
So far, I ended up with the following approach:
I created a base template for my iOS app using meteor build (not meteor run ios-device, since I did not know if Meteor does some optimizations for production code).
Then, I copied the whole Xcode project under /platforms/ios to another loaction and used this new project as my "master" project from then on. This project is being enriched with native code, e.g. it also includes the Cocoa Pods I'm needing.
Of course, I also did not want to copy files each and every time I trigger a new Meteor build. At least, I would like to have the Staging/www folder updated, as this is happening quite frequently.
So my first (rather naive) approach was
delete the Staging/www folder in the master project
replace it with a relative link (using Xcode's linking functionality) to the Staging/www folder inside the .meteor/local/.../ios/ project
This approach did not work, since the shell script used in the Meteor Xcode project can't handle these links.
My second approach is to create a symlink on the filesystem level instead. This works as it should, and I'm able to build the project in Xcode as it should.
I could have followed the same approach for the Cordova plugins folder, but I've decided to replace the plugins manually in order to get a better control over them, even it means a bit more effort then.
Having the symlink in place also means that Xcode's version management (and also SVN which I am using for everything) will ignore everything below Staging/www, which is good in my opinion, because I'm already versioning the webapp code in the Meteor project itself.
BTW: I've started a discussion thread on hybrid mobile app on the Meteor forums as well, but so far it did not get too much attraction:
https://forums.meteor.com/t/building-a-hybrid-meteor-cordova-app-share-experiences/8212
Maybe we could follow up on Meteor-specific things there, to have the Meteor community participate in the discussion?
EDIT: I would also like to share an approach that failed completely, at least for me, maybe I was too dumb... Before I used Meteor's Xcode template as the starting point, I also tried it "the other way round", i.e. I started with my already existing Xcode app project and tried to include Meteor's / Cordova's part by hand. Using this approach, I never managed to set everything up correctly. I had lots of troubles and also had to tweak a lot of the compiler / linker flags to even get the code compiling. This grew me a lot of gray hairs. But even after I managed to get everything to compile, Meteor hang during startup - and I never figured out why.
One remaining problem I'm still facing is that Meteor's hot code push functionality seems to have some severe issues on iOS, that are also documented as GitHub issues. It can happen that the iOS app gets completely broken and needs to be reinstalled. I tried the mdg:reload-on-resume package, but this did not work as it should and made things even worse. As far as I can tell from the GitHub discussions, one should better disable hot code push until the Meteor team has addressed these issues. Breaking the app completely due to code pushes is not what my users would expect.
Unfortunately plist values (and assumably AndroidManifest.xml as well) can only be changed by a plugin:
Add entry to iOS .plist file via Cordova config.xml