There are always some third-party libraries that you will come across in iOS development, so here are some of them to tease you about.
The most active community is still Github, but there are some great libraries scattered around in Places like Google Code and SourceForge. Since the Github community is so mainstream, here are some of the most popular iOS libraries on Github.
First, I compiled a list of the top iOS libraries on Github (about 600 Repos)
In addition to checking out the daily/monthly trends, you can also check out the overall iOS Repos rankings here.
Here are some of the more popular third-party libraries:
HTTP
AFNetworking, by contrast, is by far the best: lightweight, easy to use, widely used, and actively maintained by developers. The role was played by ASIHTTPRequest before the advent of AFN, but has fallen into disrepair by now. About the AFN and ASI contrast, there is a good article www.infoq.com/cn/articles… . In addition, MKNetworkKit and RestKit have certain users.
Socket
CocoaAsyncSocket supports asynchronous TCP/UDP, GCD, and Objective-C interface encapsulation. At present, no comparable products have been found.
JSON
JSONKit is one of the best of the third parties: high performance, few files. Before JSONKit, SBJson was very, very popular, but SBJson performance was poor enough to still exist in some projects due to historical reasons. If the project only needs to support iOS5 or higher system, then you can abandon those third-party Json libraries and directly use NSJSONSerialization provided by the system, which has better performance than the third party and is the official API.
XMPP
Now do a live chat, XMPP protocol is a very mature scheme. The XMPPFramework is a good choice for dealing directly with the OpenFire server. You can check this out if you don’t have a lot of people.
Basic tool Class
SSToolkit is a good tool kit that provides all kinds of things like encoding, encryption, string manipulation, etc. It also has some nice custom controls and is very well-documented.
The framework
A lot of people used Three20 in the past, but it was so big, so heavy, so poorly documented that even Facebook stopped maintaining it. Nimbus is now popular as an alternative, but the key is that it is well-documented. There is a DOMESTIC MVC framework called BeeFramework, claimed to be the top framework and more functions than Nimbus, you can have a look. ReactiveCocoa brings reactive programming to the table and is worth a try.
Data is stored
Many people (like me) prefer to work directly with SQLite, and FMDB encapsulates this well. If you use CoreData for storage, you can use MagicalRecord.
The image processing
GPUImage is undoubtedly the epitomization of this aspect. With OpenGL ES2.0 for real-time processing of pictures and video streams, performance and features are top notch.
Develop and debug tools
PonyDebugger seems like a great tool for remotely debugging iOS applications, viewing attempt hierarchies, networks, and more from a computer browser. CocoaLumberjack is a Log tool that claims to provide enterprise-level logs and is widely used.
To get a sense of the popularity of third-party libraries, here are some well-known apps that rely on third-party libraries.
Netease news
AppleReachability
ASIHTTPRequest
EGOTableViewPullRefresh
GTMNSString+HTML
MGTemplateEngine
MPOAuth
RegexKitLite
SDWebImage
SSZipArchive
wax
Garageband
MurmurHash
libpng
zlib
SBJson(json-framework)
IWork suite of three
MOKit
Boost C++ Library
protobuf
OpenGL Mathematics
SQLite
cephes math library
AFNetworking
AFHttpClientLogger
Facebook SDK
iRate
MAKVONotificationCenter
SDWebImage
SFHFKeychainUtils
SSPullToRefresh
SVProgressHUD
TTTAttributedLabel
TTTLocalizedPluralString
UIAlertView-Blocks
Read more
fmdb
ASIHTTPRequest
FreeType
JSONKit
Objective-Zip
Skia(Google)
MBProgressHUD
taobao
MAZeroingWeakRef
MBProgressHUD
ABContactHelper
ASIHTTPRequest
CocoaLumberjack
EGOTableViewPullRefresh
fmdb
GTMBase64
JSONKit
SBJson(json-framework)
RTLabel
SDWebImage
SVPullToRefresh
three20
ziparchive
cocos2d
EGOTableViewPullRefresh
Facebook iOS SDK
JSONKit
SBJson
ziparchive
ASIHTTPRequest
FMDB
CocoaAsyncSocket
JSONKit
MBProgressHUD
OpenUDID
SBJson
SVPullToRefresh
Baidu map
AFNetworking
GTMBase64
JSONKit
MBProgressHUD
RNCachingURLProtocol
SDWebImage
ABContactHelper
AFNetworking
ASIHTTPRequest
DACircularProgressView
DDProgressView
DTFoundation
fmdb
JSONKit
SBJson
MBProgressHUD
MTStatusBarOverlay
OpenUDID
SFHFKeychainUtils
everyone
cocoaasyncsocket
ZipArchive
MBProgressHUD
JSONKit
GTMBase64
MKNetworkKit
HPGrowingTextView
zxing
As you can see, these big apps have very confusing dependencies, so explain a little bit. These big companies all have an iOS team to work with, and the level of team members is very uneven. Sometimes for historical reasons, for example, a component of an App relies on ASIHttpRequest, but later newcomers switch to AFNetworking, resulting in confusing library dependencies. This leads to problems such as difficulty in maintenance and code redundancy. Therefore, the introduction of a third-party library must be carefully considered, if possible, try to develop and implement the corresponding functions, third-party library as far as possible for reference only. Small teams or individual developers don’t have to worry too much about speed.
One final tease about Cocoapods.
The popularity of a language is always accompanied by the enrichment of third-party libraries, and the corresponding emergence of tools that rely on library management. Cocoapods is to ObjC what Maven/Gradle is to Java and gem is to Ruby. Cocoapods is basically built on the Github community, is open source and has an active community. In addition to using a central repository on Github, you can also build your own private server and mess around.
As far as I’m concerned, I don’t recommend using Cocoapods.
1. Tools like Maven are built to manage massive third-party library dependencies, control versioning, build engineering, etc. It’s hard to imagine a Web project that relies on hundreds of JARS to manage builds without packages. However, iOS development is client-side development ah, if there is really a project that relies on so many third-party tools, can the App remain stable? Usually an iOS project doesn’t have that many package dependencies.
2. Generally speaking, you can’t have too many projects going on at the same time, nor can you create N apps to launch in a single day. Cocoapods saves less rework than it causes more trouble.
3. Inconvenient modification and debugging. If a third-party library needs a small amount of modification to fulfill its requirements, using Cocoapods can be cumbersome.
As for third-party libraries, it is also not recommended to use them too much.
1. Time consuming, an open source library, which requires careful inspection of the code quality, to confirm whether it is reliable enough. If problems arise, the internal implementation of the open source library needs to be carefully examined. If these tasks are too time-consuming, do them yourself.
2. Poor maintainability. In case of system upgrade and API replacement, third-party libraries cannot ensure that there are no problems. It is also difficult to find people to maintain when something goes wrong. If you follow up on changes to third-party libraries, new problems can still arise.
3. Legal issues. Big companies need to scrutinize licensing agreements, but small companies are not afraid.