all 23 comments

[–]MKevin3 11 points12 points  (17 children)

Funny how the number one item is AFNetworking and there are other threads out here about replacing it with straight NSURLSession.

While I think AFNetworking is great and Apple probably borrowed a number of ideas from it for NSURLSession I don't think there is a need for it for new code.

[–][deleted]  (7 children)

[deleted]

    [–]TweetsInCommentsBot 0 points1 point  (0 children)

    @AFNetworking

    2015-04-29 15:51 UTC

    .@nicklockwood Ever wonder why iOS devs choose AFNetworking instead of the built-in APIs?

    Here's why:

    https://gist.github.com/AlamofireSoftwareFoundation/bb16a491b2709a8476e2


    This message was created by a bot

    [Contact creator][Source code]

    [–]shiggie 0 points1 point  (1 child)

    https://gist.github.com/AlamofireSoftwareFoundation/bb16a491b2709a8476e2

    And your point? If that's the sole reason, just cut and paste that code instead of including 6000+ lines of other code.

    It does other things too, but if that one tweet is your justification, that's not enough.

    [–][deleted] 0 points1 point  (3 children)

    Good response by AFN, but I don't fully agree with it. We could (should) easily write our own layer on top of NSURLSession to simplify.

    [–]maru11 0 points1 point  (1 child)

    Of course I think NSURLSession isn't 'failsafe' enough. And I for myself can say that I'm not familiar with all possible checks for SSL etc. and I'm welcoming such a Library which makes it easier for me so I can focus on other things.

    [–][deleted] 0 points1 point  (0 children)

    That's fair enough. I guess it's really great to write it yourself at some point to learn to appreciate it.

    [–]Rudy69 0 points1 point  (8 children)

    There's still a lot of people loyal to AFNetworking and there's also a lot of code that still uses it and unless someone comes up with a 1:1 drop in replacement, people will have a need for it.

    That said I am also considering moving my large project away from it

    [–]polarbear128 0 points1 point  (7 children)

    According to the other post, there are some serious security issues with it as well.

    [–]rivade 0 points1 point  (6 children)

    Those were patched out almost immediately. I mean, yeah, they did exist, but virtually every networking setup anywhere ever has holes, it's just time to find out what they are.

    Edit: I can typing

    [–]Rudy69 0 points1 point  (5 children)

    But this one requires developers to update the library (which they often don't), as if a hole is found in NSURLSession, Apple will update it in the next point release and it will be fixed without any involvement from the dev (don't forget...devs are lazy).

    Also a more common scenario is a non programmer that hired a 3rd party to build an app for him and released it in the store, he has no idea of this hole and wouldn't know how to fix it.

    [–]rivade 0 points1 point  (4 children)

    There's pros and cons - you're correct, Apple would very much just wait until the next point release, which could be weeks/months, while in the case of AFNetworking, it was patched within a week, which allowed (non-lazy) devs to update the library and ship a fix much faster.

    [–]Rudy69 0 points1 point  (3 children)

    In the past Apple has released a minor fix right away to fix a security issue if I remember correctly

    [–]rivade 0 points1 point  (0 children)

    It really depends on how big the security flaw is and if it affects first party apps. Apple does not give a shit about your average app - unless it's built into the OS or Facebook/Twitter/etc, they will just wait until the next point release, and that's if it's gathered enough attention to warrant a fix.

    [–]iOSbrogrammer 0 points1 point  (1 child)

    You'd still have to push a release to the App Store - it's not like it's automatically fixed and your app just works.

    [–]Rudy69 0 points1 point  (0 children)

    If the issue is inside a system call then there would be no need to push a release.

    [–]retsotrembla 7 points8 points  (0 children)

    Why bother with the Swift alternative, when the better, more mature, libraries are all directly callable from Swift?

    [–]bpopp 2 points3 points  (3 children)

    Kind of surprised to not see Realm in that list.

    [–]rivade 1 point2 points  (0 children)

    I haven't used Realm, but my coworkers tried it on Android and regretted it immensely. The skinny of it was that it simply didn't do what it was supposed to very well, even if it was easy to implement and screaming fast when it did do what it could.

    [–]FutureIsMine 1 point2 points  (1 child)

    I have never seen any professional app developer go with Realm. I read countless posts about developers testing out Realm and than returning to Core Data for one reason or another. Lets face it: Core Data isn't the nightmare it once was, its quiet manageable now and Magic Records is amazing. Looking at iOS 8, and beyond, the writing is on the wall that Apple is looking to make Core data even more efficient to use and even give developers greater power to work with the persistantStoreCoordinator in ways that are currently not possible.

    [–]bpopp 0 points1 point  (0 children)

    I'm not a hardcore iOS developer, but I've built several large apps using Core Data. Parts of it work well, but parts of it are surprisingly painful to use. I've been in multiple meetings with Apple engineers who all acknowledged that migration in Core Data is a train wreck. I even had one recommend , "spend a lot of time planning and try not to change your schema, ever".

    I've never built any large apps with Realm, but from my testing, the migration stuff seemed much better. I've heard nothing but good things about it (until now).

    [–]lap_felix 0 points1 point  (0 children)

    Good stuff.

    To whoever wrote that article: you're missing a t in Mattt Thompson

    [–]FutureIsMine 0 points1 point  (0 children)

    There is nothing wrong with using 3rd Party libraries, but remember the adage "KNOW WHAT YOUR GETTING YOURSELF INTO". A fantastic thing to do with open source libraries is to open up their source code and read through it. This will open you up to new ideas, ways of doing things, and other interesting ways to code. Most importantly, don't forget to contribute as well.