Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Libraries Used in the Top 100 iOS Apps

medium.com

Post reply on HN
Print view View original

21–30 of 54 posts

Re: Libraries Used in the Top 100 iOS Apps

#21

Post by smilliken »

aresant wrote: post #7

Slightly off-topic but we're in the middle of building an iOS / Android SDK / library to drive improved location services. Does anybody have any solid resources on SDK marketing directly to iOS and Android developers? We've found some innovative ways to address the community (doesn't hurt to have an office packed with engineers to ask where they find solutions) but looking for ideas ranging from the best developer ev…

We (MixRank) help several SDK companies track apps that are using location services. This can be very useful for sales, marketing, and business intelligence. Reach out of you'd like to chat.

Re: Libraries Used in the Top 100 iOS Apps

#22

Post by baddox »

chrisBob wrote: post #11

Anyone know what is wrong with the table? When I try to highlight text (so I can find out what Flurry-iOS-SDK is) it lets me click, but then scrolls rappidly to the top of the page when I move the mouse to highlight something (Safari on OS X).

Looks like it's an embed of a CSV file on GitHub, which is cool, since I didn't know GitHub supported that, but they've definitely got some funky JavaScript that doesn't play nice on mobile.

Re: Libraries Used in the Top 100 iOS Apps

#23

Post by mwcampbell »

I notice that no off-the-shelf web view wrappers (e.g. PhoneGap/Cordova) or non-web-view JavaScript frameworks (Titanium, NativeScript) are in this list. Would Xamarin, RoboVM, or RubyMotion be detectable with this method? Or can we safely assume that all of the top 100 apps are native ObjC or Swift?

Re: Libraries Used in the Top 100 iOS Apps

#24

Post by NateLawson »

smithclay wrote: post #8
CyrusL wrote: post #4

Interesting sidenote: I saw a reply to this post on Twitter where SourceDNA commented how the makeup of the top 100 apps differs from the long tail of apps: https://twitter.com/SourceDNA/status/652247709655547905 https://twitter.com/SourceDNA/status/652247927289544704 "CocoaPods is less popular in the top 100 apps than the long tail. We see ~180K apps with AFNetworking." "CocoaPods more popular in apps that aren't to…

Anyone done any analysis on what top 100 apps are using Swift? Similar to the cocoapods note, my guess is it's catching on much faster with the long tail than the most popular apps.

Developer behavior is pretty varied along a number of angles. Since even indie apps can hit the top ranks (especially in games), it's a little less useful to talk about apps by rank and instead more by company background.

Swift is growing but not huge yet. Certainly there has been a flood of experiment apps in the long tail, where someone used it as a learning exercise. Some of the larger companies are using it for a new project once in a while, but it's certainly been most popular in games.

What never ceases to surprise me is the influence a single developer can have, even in a large organization. Someone picks up a tool and then suddenly it's used everywhere in the company.

Re: Libraries Used in the Top 100 iOS Apps

#26

Post by gorena »

aresant wrote: post #7

Slightly off-topic but we're in the middle of building an iOS / Android SDK / library to drive improved location services. Does anybody have any solid resources on SDK marketing directly to iOS and Android developers? We've found some innovative ways to address the community (doesn't hurt to have an office packed with engineers to ask where they find solutions) but looking for ideas ranging from the best developer ev…

Is this going to be open source? Or a commercial product? I don't think most iOS devs would want to use a closed-source library, not necessarily because they're averse to paying for something, but because the UX of using one is much worse.

- There's generally no dependency management, or you're forced into using Cocoapods, and using it in a bad way (binaries in your repo).

- You're at the will of the vendor for additional features (framework, Swift nullability/generics integration, bitcode), and, if they're even available, dependency bumps. This gets really painful. Every time I used a closed-source framework, it ends up being a nightmare.

This is compared to:

- Add line to Cartfile

- carthage update

- A little drag and drop

- Done, future releases will probably Just Work

You might have better luck with people that aren't necessarily "iOS devs", i.e. games, where using closed-source is more common and they might not even be using Xcode.

Re: Libraries Used in the Top 100 iOS Apps

#27

Post by NateLawson »

mwcampbell wrote: post #23

I notice that no off-the-shelf web view wrappers (e.g. PhoneGap/Cordova) or non-web-view JavaScript frameworks (Titanium, NativeScript) are in this list. Would Xamarin, RoboVM, or RubyMotion be detectable with this method? Or can we safely assume that all of the top 100 apps are native ObjC or Swift?

The approach Ryan used was to look at ObjC classes, but you're right that many SDKs and tools don't show up there.

We actually scan millions of apps from the app stores. Here's a public view of the top 500 in US, and if you choose the cross-platform category, you can see apps like this. For example, "Pac-Man 256" is rank 28 (Unity), Amazon is rank 30 (Cordova), etc.

https://sourcedna.com/stats/

It's actually very difficult to accurately match code written in so many different languages as compilers discard a lot of the info you need. I spent a lot of time researching and evaluating different ways to fingerprint libraries, as well as reconstruct the boundaries of internal modules when there weren't any symbols.

We match code by using a similarity search across all components we've ever seen. Since code written in C can be compiled to x86 or ARM, we disassemble the code into an intermediate language. Then we reconstruct control-flow graphs, data dependencies, and other platform-independent features. We index these in a custom search engine, which allows quick lookup and matching.

It's very difficult, but ultimately a really fun problem to solve. Most of our engineers got started with exactly the exercise Ryan did here. :-)

Re: Libraries Used in the Top 100 iOS Apps

#28

Post by eljimmy »

mwcampbell wrote: post #23

I notice that no off-the-shelf web view wrappers (e.g. PhoneGap/Cordova) or non-web-view JavaScript frameworks (Titanium, NativeScript) are in this list. Would Xamarin, RoboVM, or RubyMotion be detectable with this method? Or can we safely assume that all of the top 100 apps are native ObjC or Swift?

I would expect that if an app is popular enough to be in the top 100 then it most likely has the bankroll to pay for native devs.

I can't imagine ever seeing a non-native app in the top 100 with the exception of maybe ReactNative-based apps which is a bit of a grey area since it compiles into native.

Re: Libraries Used in the Top 100 iOS Apps

#29

Post by akiselev »

mwcampbell wrote: post #23

I notice that no off-the-shelf web view wrappers (e.g. PhoneGap/Cordova) or non-web-view JavaScript frameworks (Titanium, NativeScript) are in this list. Would Xamarin, RoboVM, or RubyMotion be detectable with this method? Or can we safely assume that all of the top 100 apps are native ObjC or Swift?

I don't see why Xamarin wouldn't be detectable but I don't think it would appear as a separate library. Due to the impedance mismatch between C# and ObjC, Xamarin has to generate proxies and wrappers as well as deal with some abstraction leaks.

However, iOS (afaik) doesn't quite have shared libraries like you would have on a Linux server and there's no point in creating a separate ObjC library that would add bloat to each Xamarin binary because the C#-to-ObjC transpiler can selectively generate the wrappers/proxies during compilation. Xamarin might not even use a code generator to do that because you can just include all the ObjC code with the transpiler and copy-paste include them into the project at will.

Re: Libraries Used in the Top 100 iOS Apps

#30

Post by Velox »

gorena wrote: post #17
ianstallings wrote: post #6

Earlier quoted context omitted.

Because they're not going to rewrite or replace code that already has been tested and works in production.

Using an unmaintained networking stack should terrify you.

Just because it's old doesn't mean it's unmaintained.
Post reply on HN