I'm very new to iOS/Objective C development, so this is very probably a very easy question to answer. I'm building a project whih uses the SignalR-ObjC library, which is an Objective C implementation of SignalR.
To download and install the library, the SignalR-ObjC website says to use Cocoapods, which I have duly done. However the version of SignalR-ObjC available over Cocoapods is not the most recent version, and there's a more recent version on GitHub. I need to use the latest version as I'm told that there are some bugs in the old version, and I want to use some of the more recently added features.
I've tried as couple of ways of updating the SignalR-ObjC library, but can't quite seem to get it right.
For an iOS ObjectiveC project which uses libraries downloaded through Cocoapods, how do I update one of the Cocoapods libraries with code downloaded from GitHub?
You can write 'SignalR-ObjC', '2.0.0.beta3' to your Podfile. This will download the latest SignalR library and subsidiary libraries that are needed to run the library.
Related
So, we need to integrate a library in our application, which is gonna be developed by another organization. This library will wrap some other, external, libs and export them to our app + an small sdk to handle a specific flow. At the end, this sdk is going to make some network calls.
The developers of the library are asking us to provide dependencies if any and how to distribute the lib.
We will agree on cocoapods, minimum sdks, and i think its wise to tell them to use the same swift version we are using as well as the same Alamofire version.
Any other suggestions?
Thanks all in advance!
If you are using cocoa pods for the integration of the plugins, the resolving of the dependencies will be managed by cocoa pods. In the .podspec file of the plugin, you can define dependencies of the plugin itself. (podspec documentation)
If you are currently developing the plugin you might hit some incompatibilities, but if you have contact to the developers of the plugin, those should be solvable.
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/
Im planning to add a text within an app stating what RestKit version the app is currently using. So I wonder if there is an easy way to get the current version number of the RestKit installed via CocoaPods.
...Or, is there a way to check the version of the staticlib libPods-RestKit.a?
No, there isn't. The version number is held in a file in the project but this file isn't built into the library and there is no API provided to get the version number. There is no standard method for providing version numbers in static libraries so this isn't a frequent requirement.
Anything you do would be an explicit solution on your part. Your best option would likely be to fork the RestKit repo and make some small changes or to reference the VERSION file from the RestKit project in your main project so it's copied into the app and you can read it from disk at runtime...
I am following this tutorial
The tutorial states to add libz.1.2.3.dylib. library, but because I have downloaded newer or older library (I don't know exactly if my library is newer or older that the library in the tutorial, but 99% it is newer). So, when I tried to add the libz.1.2.3.dylib. library, I didn't find it. However, when I typed libz I found these choices:
which one should I choose please?
In using dynamic libraries the one you normally use is libX.major_version.dylib in this case libz.1.2.dylib. This is a link to a library libX.major_version.minor_version.dylib which here is libz.1.2.5.dylib
The rationale for this is that the major version is changed only when the API is changed, the minor version is updated when any change is made. Thus your program should work when it uses any of the same major version and so you want the latest version.
In this case the tutorial had an older install and so its libz.1.2.dylib. should have pointed to libz.1.2.3.dylib.
For you you should use libz.1.2.5.dylib which should be like the tutorials version but with bug fixes and possibly extra functions that don't matter here as the tutorial won't call the new functions.
Normally libX.1.x.dylib would be older than libX.2.y.dylib but the writers might produce bug fixes to the old API whilst also working on the new API
Following on from the rational I gave libz.dylib should be a link to the highest number library but I would not use it as you are writing to a particular API so I would use a version specific (In this case if missing a link the I would not trust what libz.dylib points to)
The latest version of Delphi, XE4, allows for the building of iOS applications. There was some discussions on the newsgroups to use native iOS libraries for HTTPS/Posting to avoid issues with OpenSSL libraries and Indy 10. What's the recommended way of using native libraries to perform HTTP Posting? (In my example, JSON document upload and response.)
I figured it out...
Background:
Indy, the "native" code used for webservice calls in XE4, relies on OpenSSL. In most situations, OpenSSL is linked to via dynamic library (in windows a DLL). iOS does not support dynamic libraries, therefore once the code is compiled into a binary and sent to an iOS device, the OpenSSL calls fail because there is no backing library. The solution is to compile OpenSSL into your project. You can do this by downloading the OpenSSL source and adding it to your project, or source the static libraries from somewhere else and add them to your project. I found the static libraries here:
http://indy.fulgan.com/SSL/OpenSSLStaticLibs.7z
That is one of the indy mirrors, so hopefully it should be OK. You need to put the two files somewhere that your project is knowledgeable of and then add IdSSLOpenSSLHeaders_Static to your uses. Now, your compiled code will include the OpenSSL code and your issue should be resolved.