Slashdot Mirror


How a Mobile App Firm Found the XcodeGhost In the Machine (computerworld.com)

SpacemanukBEJY.53u writes: A Denver-based mobile app development company, Possible Mobile, had a tough time figuring out why Apple recently rejected its app from the App Store. After a lot of head scratching, it eventually found the XcodeGhost malware hidden in an unlikely place — a third-party framework that it had wrapped into its own app. Their experience shows that the efforts of malware writers can have far-ranging effects on the mobile app component supply chain.

69 comments

  1. And that's by Anonymous Coward · · Score: 0, Interesting

    Why I use make and Code::Blocks on OSX (And Linux, And BSD... Still use VS on Windows though. Gotta love me some Intellisense.)

    The big problem with xcode? Gotta have an Apple account...

    1. Re:And that's by _merlin · · Score: 4, Insightful

      Using a different build tool won't protect you from an infected 3rd-party library.

    2. Re:And that's by Anonymous Coward · · Score: 0

      If you read the damn article, the third party lib was in a bad copy of Xcode. People downloaded Xcode from somewhere other than Apple, and in that build of Xcode was the infected lib.

    3. Re:And that's by _merlin · · Score: 2

      You're completely missing the point of the article: it doesn't matter if your development environment is clean if a library you use was built in a trojanised environment. Whichever IDE or build tool you use the same applies. It wouldn't have mattered whether the app developer used clean Xcode, clean Code::Blocks, or whatever, the malware got into their app by way of a third-party library built with a bad copy of Xcode. The moral is, be careful who you trust.?

      (Also, can you actually develop for iPhone/iPad with Code::Blocks anyway? Don't you need to use Xcode in some form for the signing process to work? I could be wrong, I've never actually developed an iApp, but I suspect AC hasn't either.)

    4. Re:And that's by aaarrrgggh · · Score: 1

      You must not have read the article-- it was a third party binary library compiled on a trojaned Xcode.

      Curse you for making me read the actual article... "Using a command line tool, grep, to search the library for known URLs..." Wow! Rocket Science! Makes me want to never purchase an app from the company that paid for the advertisement...

    5. Re:And that's by angel'o'sphere · · Score: 2

      XCode is only an IDE. Under the hood it uses ordinary command line tools, so signing by using a different IDE is only a matter of calling the signing tool with the right parameters.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    6. Re:And that's by Anonymous Coward · · Score: 0

      It serves as a quick and effective way to find traces of XcodeGhost in a compiled binary. Did you have a better solution to offer developers?

  2. He Whom Haseth Smellteth It Hatheth Dealteth Iteth by Anonymous Coward · · Score: 0

    ! x 2

  3. Re:Why I favor "1 part stand alone exe" design by SirSlud · · Score: 2

    Old man yells at iCloud. (And man, I'm old. That's just a joke that applies in this case.)

    --
    "Old man yells at systemd"
  4. WHY? by H3lldr0p · · Score: 3, Insightful

    I don't understand why, as a commercial, professional developer you didn't take the time to find or demand a copy of the code from a third party plug-in. And if you couldn't do that, why you'd still go and use it. That seems like a huge amount of built-in trouble.

    Can it be cheaper to not do your homework? Certainly! But look at what it costs you. You now have an app that's getting rejected by the publisher. You've now gone and tarnished your brand and reputation. And you've likely opened up your users to all kinds of possible trouble, not to mention any future ramifications of the if/when their data is stolen.

    Why not just do the homework and be safe from the start?

    1. Re:WHY? by dgatwood · · Score: 4, Insightful

      Ads. Unfortunately, most of the advertising frameworks out there are closed source. And buggy. I've spent way more time than I'd like working around bugs in closed source frameworks by hot-patching system libraries to prevent them from doing things that cause problems (leaks, crashes, etc.). But if you want to show mobile ads from those companies and get paid, your only option is to use their frameworks, and to deal with their closed-sourcedness.

      Annoyingly, neither the Slashdot story nor the linked story nor the blog post linked from there contains the name of the actual framework. So someone who should have known better, whose reputation should get tarnished, doesn't get his/her/their reputation tarnished, all the while exposing potentially a quarter million developers to the risk of getting their reputations unfairly tarnished by this poorly created framework. That's seriously uncool.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    2. Re: WHY? by Anonymous Coward · · Score: 0

      I don't understand why, as a commercial, professional developer you didn't take the time to find or demand a copy of the code from a third party plug-in.

      Then you don't understand the industry. Commercial, professional software is closed source for the vast majority of cases.

    3. Re:WHY? by Anonymous Coward · · Score: 0

      The people on here complaining so much about ads are probably the very same developers who would build an app around a closed-source framework.

      Sometimes the loudest critics are also the biggest part of a problem.

      I have no issue with ads because I ignore them.

      Ironically the malware that people complain about is usually the malware that is crap, and was probably half-DESIGNED to get detected. A bunch of slow crappy ads (slashdot, anyone?? leave the browser open and come back a couple hours later, my browser has ALWAYS crashed) are not a sign of the end-times, just a bunch of idiot webmasters.

    4. Re:WHY? by Anonymous Coward · · Score: 0

      I don't understand why, as a commercial, professional developer you didn't take the time to find or demand a copy of the code from a third party plug-in. And if you couldn't do that, why you'd still go and use it. That seems like a huge amount of built-in trouble.

      Let me guess. You're not a mobile application developer, are you?

    5. Re:WHY? by Anonymous Coward · · Score: 0

      My host file takes care of the ads on Slashdot normally. I think if I used my account, it wouldn't show ads, assuming that thing is still offered (not a paying customer).

      However, there is that awful, awful sponsored ad thing at the bottom of the page on Slashdot.

    6. Re:WHY? by Dog-Cow · · Score: 1

      If you weren't so completely ignorant of the fact that you're completely ignorant, you might be a passable human being. As it is, the cows are better company.

    7. Re:WHY? by Anonymous Coward · · Score: 0

      A few things. First, if a client wants to use a particular third-party framework and that third-party developer doesn't want to give you their source code, you're not necessarily in a position to demand it unless you're prepared to walk away from the work your'e being paid for. Second, the iOS App Store has been around for 7 years. In that time, countless developers have made use of third-party frameworks for everything from push notifications, to ads, to analytics, to crash reporting, etc. Very few of those developers have the time or people to audit the source code of of those libraries and in many cases, the source code isn't available. They bank on the fact that the third parties have a reputation and have been used by many others without incident. XcodeGhost was uncovered last month. It is the first instance we've seen of the iOS development toolchain becoming infected like this. This wasn't a persistent threat that developers had become accustomed to being mindful of; it caught much of the community by surprise. Most developers have not been insisting on the ability to audit third-party library code for the same reasons they don't demand to see Xcode's source code or sift through gcc's source code. 1) It's not always an option and 2) even if it is an option, the time and effort required for most developers to do this simply isn't worth the potential benefit. You talk about the potential of a tarnished brand and reputation, but the alternative for a dev shop that required source code and audited all third-party libraries could easily be never becoming a successful business in the first place.

  5. Unlikely place? by Anonymous Coward · · Score: 1

    How is that third-party library an unlikely place to contain malware?

  6. Non story by rebelwarlock · · Score: 0

    "We downloaded a plugin and it had malware in it" is not a story. Don't give these clowns any more attention than they've already received.

  7. Only a fool would add libraries without knowing wh by Dr_Marvin_Monroe · · Score: 4, Insightful

    From the supposed CTO...."Trying to figure out what is in a binary is what security researchers do, not app developers, Graves said. After scratching their heads, they guessed that the problem was probably in a third-party framework.". Sorry, you're wrong, that's exactly what app developers are supposed to do.

  8. Today I learned: Avoid Possible Mobile by Anonymous Coward · · Score: 0

    Thank you for warning me about this company.

  9. Re:Only a fool would add libraries without knowing by dgatwood · · Score: 4, Interesting

    App developers have only limited time to devote to such things. Sure, when we integrate a brand new framework, we dig in a bit to see if there's anything suspicious, but apps have to routinely update these third-party frameworks to the latest versions to fix bugs and crashes. It just isn't practical for developers to give that level of scrutiny to every minor update. If we did, we'd never have time to do anything but update third-party frameworks.

    This is, BTW, why framework developers should not be in the business of supplying precompiled binaries. The framework devs are causing added security risk for app developers, and also exposing themselves to significant liability if they make a mistake like this. And when Apple has to make a compiler change for something like app slicing or whatever, closed-source frameworks cause huge overhead for developers that wouldn't exist if all the code were being compiled by the actual developer. And when there are bugs (which there always are), closed-source frameworks make working around them a big headache. So they really are a nightmare for us.

    And trust me when I say that there's nothing in your ad or analytics framework that is so amazing that it qualifies as a competitive advantage. If you think otherwise, you're only kidding yourselves. Just open the source already.

    But I digress.

    --

    Check out my sci-fi/humor trilogy at PatriotsBooks.

  10. What am I missing? by Anonymous Coward · · Score: 0

    This whole article is completely whacked. It couldn't be more clear that these guys have absolutely no idea what they're doing.

    Xcode does not support bundling dynamic libraries with iOS applications. It's strictly prohibited by the app store because Apple's signing process only verifies the application binary, and nothing else. That means that any code you download from the internet is going to be distributed as a static library. Anything you use from that library is going to be included in your application binary, and therefore when Apple says "your application contains code that wasn't built with a legit version of Xcode", they're 100% correct.

    So if your Xcode installation is verified, and your source code is clean... what else could it possibly be? I wonder how much time they billed their clients for this clusterfuck while they went on a wild goose chase trying to figure out what the hell the problem was.

    Furthermore, what really gets me, is that they claim to have contacted the offending vendor and gotten a clean version of the framework. How do you know that version of the framework is clean? At the bottom of the same fucking article, they say that they've already heard of a new version of XcodeGhost that employs obfuscation so you can't grep around in the binary file for known strings. How do they know their vendor didn't give them a version of the framework with this new and improved version of XcodeGhost?

    I like how they don't even mention what the framework is to begin with. I'm guessing it's some super shady tracking/analytics/advertising package. But don't worry, because they'd never ship an application without such important core functionality! What a load of rubbish. I'll make note to avoid these guys in the future if I ever need to outsource any development work.

    1. Re:What am I missing? by Dog-Cow · · Score: 1

      If you weren't an ignorant no-nothing, you wouldn't have to be a coward. iOS has supported dynamic frameworks since iOS 8. The current release is 9.1, and 9.2 is in beta. Also, Xcode has supported linking to pre-compiled third-party libraries since forever, so the dynamic part doesn't matter in the least.

    2. Re:What am I missing? by Dog-Cow · · Score: 1

      I am not sure if my typo is ironic or oddly appropriate. You're still a know-nothing.

    3. Re: What am I missing? by Anonymous Coward · · Score: 0

      I don't know either, but you're still a douchebag. Every single post of yours on this story is a flame. Does it make you feel big?

  11. Why Don't Apple Adopt MS' MRT? by Anonymous Coward · · Score: 0

    At each major update, Microsoft launches its latest Malware Removal Tool which I believe is the longest running part of the update process but at least they are checking their OS for malware infected components. Why can't iOS App store has something similar? And please retrograde this shit. There is no way I'm updating my iOS7 iPad2 to iOS9 and brick it. Now that would be true definition of malware: "No need for malware guys, just install our latest iOS update on a device which we said it will defo run. And then your only option when it's broken is to come to us to buy a new model or pay £144 out-of-warranty repairs!"

    1. Re:Why Don't Apple Adopt MS' MRT? by Anonymous Coward · · Score: 0

      Apple does actually include a "Malware Removal Tool" as part of OS X updates, probably also iOS updates.
      Not too much malware to remove yet, so you only see it once a year or so in a comment of a security update.

      With iOS malware are still signed applications which can get their keys revoked and distributed by the App Store.

  12. Apple no longer looks as paranoid as it did. by tlambert · · Score: 3, Insightful

    Apple no longer looks as paranoid as it did.

    Previously, they did not permit the use of third party libraries in your application; everything had to be built or sourced by you, because there's no intermediate library signing and vetting process that Apple can do on your behalf. They relaxed this when developers screamed like a stuck pig.

    They are looking a lot less paranoid in their prior restriction, now.

    I'm happy that Apple was clever enough to reject the App, and somewhat disappointed that the developers had such a hard time reading the rejection notice that they were left scratching their heads.

    1. Re:Apple no longer looks as paranoid as it did. by Anonymous Coward · · Score: 0

      As it once did? Apple was a great vector for malware in the early days. Even into the 90s there was a need for third party applications to do access control. They were not alone in this regard.

    2. Re:Apple no longer looks as paranoid as it did. by Bogtha · · Score: 1

      Previously, they did not permit the use of third party libraries in your application; everything had to be built or sourced by you, because there's no intermediate library signing and vetting process that Apple can do on your behalf. They relaxed this when developers screamed like a stuck pig.

      This has never been true and the bit about developers screaming like pigs is pure fantasy.

      Perhaps you're getting it muddled up with the fact that iOS didn't support dynamically linked libraries? In any case, not many developers cared, we all just used statically linked libraries.

      --
      Bogtha Bogtha Bogtha
    3. Re:Apple no longer looks as paranoid as it did. by Dog-Cow · · Score: 1

      How does shit like this get modded insightful?

      Apple has allowed iOS apps to link to 3rd-party precompiled libraries since the iPhoneOS 2.0 SDK was released (that was the first public version). Even if you meant frameworks, you are incorrect.

      What you couldn't do is dynamically link. That restriction was removed in iOS 8.

  13. Re:Only a fool would add libraries without knowing by Anonymous Coward · · Score: 0

    Every time Apple uses the word "framework", Jesus kills a library. Think of the libraries!

  14. What third party library by EmperorOfCanada · · Score: 3, Insightful

    Name some names. Telling me that some random third party library out there has this is a huge pile of steaming useless information. Name some names.

    1. Re:What third party library by Anonymous Coward · · Score: 0

      It doesn't matter. They'll just rename it and republish it.

    2. Re:What third party library by Anonymous Coward · · Score: 0

      The original blog post has information on how you can scan your own third-party frameworks, the purpose being that developers should be aware of the risk in all cases, and be able to scan for the problems themselves. Calling out a single company would only provide a scapegoat and give developers not using that third-party framework a false sense of security.

  15. Re:Only a fool would add libraries without knowing by Anonymous Coward · · Score: 0

    From the supposed CTO...."Trying to figure out what is in a binary is what security researchers do, not app developers, Graves said. After scratching their heads, they guessed that the problem was probably in a third-party framework.". Sorry, you're wrong, that's exactly what app developers are supposed to do.

    Then perhaps you would like to explain the purpose of a security researcher/analyst position otherwise? It's not like the parent just pulled that job out of their ass for this argument, and based on the amount of shitty code being banged these days, we could use the extra scrutiny, which feeds the irony of this very topic.

  16. Re:Only a fool would add libraries without knowing by Anonymous Coward · · Score: 0

    I promised to never post here again, but you seem legit. Your argument is the same as all those BS psych/medical researchers who just "need to do it to survive", meaning phack and not replicate each other and have shitty vague theories. This has gone to an extent that it is destroying every pillar of civilization that was built by those before. Guess what, being a pawn in destroying what is great is not a worthwhile life. Go do something better.

  17. Re:Only a fool would add libraries without knowing by Anonymous Coward · · Score: 0

    Where does it stop? When we've checked every framework/library source and compiled it ourself? Or should we also write our own compiler in machine language and then compile our open source operating system. Perhaps even that is not enough, think of the closed source firmware we're dealing with every day..

    I bet if that's the entry level the app stores will be pretty empty.

  18. Why I favor "1 part stand alone exe" design by Anonymous Coward · · Score: 0

    See subject: Dependencies only on native system level API from libs/dlls already present in the OS. "Web apps" stuff? Too many "moving parts" - sorry webboys, but this is part of the price you're paying for "convenience & ease" which this article evidences.

    So what else can do what these things do? DCOM/Corba!

    However - to master them is more difficult (by far) but webservices type design made it easy for just about anyone to join the party (which I suppose, has its merits) but this article's topic's the price paid.

    Yes DCOM uses rpc. Rpc has some 'holes' too but then again, how many of those do you see in comparison to 'web app' flaws popping up for years now? Not that many.

    Plus, you can stop them by following 'best practices' shown here @ Microsoft https://technet.microsoft.com/...

    This also goes for using unproven libs/dlls in "standalone" programs. I rarely did, but sometimes I had to (Crystal Reports in what I did for a living in MIS/IS/IT business development - Saves time & proven - company who produced it kept up on it, had a fortune to build & LIABILITY).

    However:

    What if development, support, or patching them stops/company goes under etc.?

    You're up the shit creek minus a paddle.

    E.G. -> I built this as "1 moving part" only APK Hosts File Engine 9.0++ SR-2 32/64-bit http://start64.com/index.php?o... & that's the reason why - I also have TOTAL control over its code.

    One of my 'competition' doesn't (HostsMan which lacks features mine has in hardcoded favorites @ top of hosts added speed above adblocking + reliability vs. DNS security issues or exploits (many)) & they used SQLite (many browsers do also) - that's fine until they go away (they probably won't though but you never know) OR don't go 64-bit (I have no idea if they do or not to be honest - feel free to enlighten me on that front) - if those things happen to it? For HostsMan it's "out go the lights".

    APK

    P.S.=> Want a job done RIGHT? Build it, ground up hands-on, yourself... apk

  19. Re:Why I favor "1 part stand alone exe" design by Anonymous Coward · · Score: 0

    Get on topic and enjoy your -1 moderation troll.

  20. Re:Only a fool would add libraries without knowing by hey! · · Score: 1

    Well what is prudent and necessary to do is a matter of what threats exist in practice. If *all* those concerns you listed proved to be popular vectors for malware you'd have to check all those things, or admit to customers your software is untrustworthy.

    Fortunately there are intermediate levels of paranoia between trusting everything blindly and building everything up from machine language. There are choices you can make about who to trust and what steps to take to verify that trust. This story demonstrates that. Apple caught the problem before allowing the app in their store, which successfully prevented the distribution of the malware in this case. The developer in turn figured out which of his vendors was at fault.

    Is that a lot of effort doing something that wouldn't be necessary in an ideal world? Sure. Is it annoying? Absolutely. Is it beyond the ability of a skilled professional developer to deal with practically? No.

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
  21. What this boils down to by istartedi · · Score: 1

    Apple can't tell you which file is bad. You have to scan them yourself.

    Nice heroic effort to track it down on their part; but I wonder if a general-purpose malware scanner could have saved them some time.

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
    1. Re:What this boils down to by myowntrueself · · Score: 1

      Apple can't tell you which file is bad. You have to scan them yourself.

      Nice heroic effort to track it down on their part; but I wonder if a general-purpose malware scanner could have saved them some time.

      I doubt its that Apple can't; its more likely that Apple doesn't want or can't be bothered.

      They may even have an ulterior motive when an app developer is creating something that Apple themselves have an app developer working on; they'll just reject the app and give no reason just to block the dev so they can bring it to market themselves, or even try to discredit a dev to blow away their business.

      --
      In the free world the media isn't government run; the government is media run.
    2. Re:What this boils down to by Dog-Cow · · Score: 1

      They might also be conspiring to lick your dog's tail.

  22. Re: Only a fool would add libraries without knowin by Dr_Marvin_Monroe · · Score: 1

    Now your just making excuses for sloppy work. As a mobile app developer myself, I check ( at least once ) any library/framework that goes into a delivery. I don't bother with the OS, as I assume Google/Apple have that covered. There, that wasn't so hard....

  23. Re:Why I favor "1 part stand alone exe" design by Anonymous Coward · · Score: 0

    He's not that old. Sadly.

  24. Re:Only a fool would add libraries without knowing by Anonymous Coward · · Score: 0

    So you're a dishonest individual who pretends to hold the moral high-ground and feels that any of their points should actually be given merit when you, yourself, can't even keep a promise to yourself. If you lie to yourself then you lie to everyone else. If you're dishonest there's no reason to read the rest of your post - indeed, I stopped there.

  25. Re:Why I favor "1 part stand alone exe" design by Anonymous Coward · · Score: 0

    stop spamming your stupid shit in irrelevant threads

    does it work in iOS or OS X? no

    your shit doesn't even work in Linux

    shit spammed programs from shitposters

    nobody of any note will actually recommend your application and twisting the guy at mbam's words to claim they recommend your application is bullshit and you know it

    or maybe you don't you demented fucktard

  26. Re: Why I favor "1 part stand alone exe" design by ememisya · · Score: 1

    Old man overdoes his medication, yells at clouds.

  27. Re: Only a fool would add libraries without knowin by angel'o'sphere · · Score: 1

    Whom on /. do you expect to believe you that?

    Sorry, there is no way that you know all the sourcecode of the libraries/frameworks you use, except you only write "Hello World" programs and 'link' the required parts as sources.

    Now go back into your cabinet and dream about your brave new world.

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  28. No, I'll do as a please... apk by Anonymous Coward · · Score: 0

    Can you stop me? Hell no, lol. Who cares what you think? You don't possess sufficient intellect to think much less create anything at all. I could easily port to MacOS X &/or Linux. I don't. Compared to Windows, they're not worth my time since the host file itself created on Windows using my ware runs on both of them (& it's what counts the most, the hosts file itself).

    You're powerless - accept it. Especially vs. me!

    APK

    P.S.=> You WISH people from the likes of Malwarebytes would host AND RECOMMEND your wares as they do mine here -> http://hosts-file.net/?s=Downl... AND YOU WISH YOU WERE ME, you jealous little dolt - only problem is, you lack the skills + intestinal fortitude to do so (& you KNOW it) - LMAO... apk

  29. Re:Why I favor "1 part stand alone exe" design by Anonymous Coward · · Score: 0

    How do you figure he's twisting the malwarebytes guys words? It's right here on his site in black and white near the top http://hosts-file.net/?s=Downl...

  30. Re:Why I favor "1 part stand alone exe" design by Anonymous Coward · · Score: 0

    Hohohohoho, jealous of apk are we? Yes. It's your fault for being a ne'er do well as he names your kind loser. I just call you what you are. A loser.

  31. Re:Only a fool would add libraries without knowing by myowntrueself · · Score: 1

    From the supposed CTO...."Trying to figure out what is in a binary is what security researchers do, not app developers, Graves said. After scratching their heads, they guessed that the problem was probably in a third-party framework.". Sorry, you're wrong, that's exactly what app developers are supposed to do.

    App developers are just construction workers, they aren't engineers, they aren't scientists.

    They just clip construction blocks together. Why would they have any clue whats inside the construction blocks? Why should they?

    --
    In the free world the media isn't government run; the government is media run.
  32. Wrong, that is what LIBRARY developer should do by SuperKendall · · Score: 1

    For iOS software, most third party libraries are brought in as source, which means you are compiling them with your own Xcode - which indeed you should know if you obtained from Apple or not. That part is very much on the application developer to ensure both the code and the build chain do not have security issues.

    Third party libraries that come in as binaries are a very different matter though. They are all from companies, who you pay money for the use of the library - since you cannot inspect the source and it's very hard to inspect a binary, generally in those cases it is fully on the company that sends you the binary to ensure it is secure.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Wrong, that is what LIBRARY developer should do by Dog-Cow · · Score: 1

      You make it sound exactly as if you have never done any professional iOS development. Ever.

    2. Re:Wrong, that is what LIBRARY developer should do by SuperKendall · · Score: 1

      I am curious what part of what I said you think does not correctly represent iOS development.

      iOS development has always leaned heavily on a lot of third party code, in part because there are a lot of great choices out there.

      Paid libraries are more rare but they do exist. I have been a developer of some, and a consumer of others. They have their place and are sometimes unavoidable... I don't know that a large number of apps use them but I'm pretty sure it's a significant percentage.

      --
      "There is more worth loving than we have strength to love." - Brian Jay Stanley
  33. devs pirate software as much as users do... by Anonymous Coward · · Score: 0

    ... news at 11pm.

    but seriously, if they weren't such cheap-ass sleazebags, they wouldn't be unknowingly pushing viruses on us.

  34. Third-party frameworks are always a risky bet by Anonymous Coward · · Score: 0

    You have to take full responsibility for whatever havoc is caused by your using someone else's software.

  35. Re:Never trust a program or library that you haven by Dog-Cow · · Score: 1

    seen the source code of or written yourself.

    The words are in English, I'll grant you that...

  36. Re:Only a fool would add libraries without knowing by Dog-Cow · · Score: 1

    So where's the link to your app's source? Oh, you mean that your rant only applies to source you want to have, but not source you write? If you're releasing binary-only apps, don't complain about binary-only frameworks. You are certainly free to only integrate those that provide source. No one is stopping you, nor is anyone forcing you to use any given framework.

  37. Re:Only a fool would add libraries without knowing by dgatwood · · Score: 1

    First, I write a fair amount of open source software. I've released source code for tools that parse source code and emit documentation, libraries for parsing and writing OMF files (Bento containers), code for parsing BIAS Deck project files (for moving content off of a dead audio software platform), various cool shell scripts (by definition, open source, I suppose), minor bug fixes to libxml2's HTML parser.... And I used to be involved in shipping a couple of Linux ports back in the day. When I have the option to open the source of code that I write, I almost invariably do so. So don't lecture me about opening up my source code. You're preaching to the choir here. Besides, in the case of the software I'm working on at the moment, the software would actually not serve the public's interests nearly as well if it were open source for reasons that I won't go into in a public forum (and no, the reasons don't involve DRM or advertising).

    Second, there's a huge difference between source code for an app that end users are supposed to use and a framework that developers are supposed to incorporate into their own products. Out of the dozens of apps that I use, I can count the number that can make or break my ability to get an app out the door on one hand. Basically, Xcode and the tools that ship as part of it. Everything else has drop-in replacements. Photoshop acting up? Switch to Pixelmator. Buggy text editor? Use another one. And so on. So the fact that those tools are closed source is of only moderate concern, with the exception of Xcode, which I very much wish were Open Source, both because it is such a critical part of the process and because it can be pretty cranky at times.

    By contrast, a closed framework is another animal entirely, because it puts the very success of software that I'm writing entirely in the hands of another programmer. They rank right up there with Xcode in terms of their ability to cause harm, because they are part of your app. If something happens in six months, and one of those ad networks starts delivering ads that cause a particular version of an ad framework to crash constantly, you may or may not be able to adequately kill that app framework in a way that gets your app back to a functional state without shipping a new version of the app and waiting up to two weeks for Apple to review. And even then, the only thing you can do is to disable one of your sources of revenue.

    By contrast, with an open source framework, if it starts crashing, you can report the problem upstream and simultaneously start figuring out why it is happening, potentially fixing the problem, or at least figuring out what edge case triggers the crash so that you can ask the ad network to temporarily suspend ads that would trigger the edge case. So this is a much, much, much better position to be in.

    --

    Check out my sci-fi/humor trilogy at PatriotsBooks.