Vine mistakenly ships iOS app with debug mode enabled | Hacker News Reader

Vine mistakenly ships iOS app with debug mode enabled

scoopnest.com

59 pointsrobbyking57 comments

Dear god, what a horrific Twitter scraping site. Here is the actual source: https://twitter.com/MattNavarra/status/669211053188849664

Thank you! That scraping site is completely unusable with privacy addons enabled.

As always, a good reminder to treat all debug text as if customers will be seeing it :)

I've always taken the opposite route, and insisted that my debug text be as profane as possible, to ensure that I wouldn't possibly ship it with them included.

99.9% of the time, this seems idiotic, and it is, but while it does force me to be careful (which doesn't remotely outweigh the self-imposed idiocy), there was this one time where it did benefit me quite impressively. when a co-worker was trying to take credit for having written a web app that he literally wrote zero code for. He would get there early in the morning before I could and schedule product demos to management so he would get all the credit for what was essentially my pet project. That all worked great for him until one of the error states insisted that the managers of the Fortune 50 company I was building this for all do something profane.

The Casper theme for Ghost (the most popular base theme people work from) has a comment at the end of its screen.css that makes me laugh:

  /* ==========================================================================
     End of file. Animations should be the last thing here. Do not add stuff
     below this point, or it will probably fuck everything up.
     ========================================================================== */

You forgot the added bonus of being incredibly childish and fun. Riddles and easter eggs are cool to.

Fair point, but that would take away half the fun of debugging for me :(

If you simply must be profane or otherwise unsuitable in your test data, at least be subtle like instead of calling a user your are testing bad use cases with "that fucker" perhaps go with naming him "Sir Henry Isambard Tomlinson".

But seriously: do be very careful with test data. While it doesn't need to be perfect it should never be potentially offensive, childish, or otherwise unprofessional. You never know when an accident will happen and your test case data accidentally escapes into releases or other material that goes to a client or prospect (I once saw unprofessional looking test data in a screenshot in a printed brochure - good luck changing that after the fact!) or when someone in sales will find the official demo site not working so decides to show a prospect a dev/test/qa instance instead (sales having access to such app instances may be a problem in its own right, but it happens).

It isn't even just outsiders you need to worry about: someone here was officially disciplined last year when someone else in the team took offence to certain expletives being used in test data. He'd assumed no one else would see it as he was the only person on the task at the time, but as priorities changed so did who was looking at that piece of work.

At a previous job, we had test data that used an outdoor outfitter theme. We had values for canoes, fishing poles, tents, etc. under the name "Master Bait & Tackle".

It was an in-house joke, until the sales department saw how complete the data set was and wanted a copy for presentations...

So, one thing my company does is that we have git hooks preventing any file containing "DBG" from being committed. Our logging system's debug level is called DBG.

Thus, debug-level logs are only for temporary debugging and can't be committed. Several times, I've written lines of debug logs that consisted of log.DBG("Well, fuck") knowing that they'd never be committed and that we have technical means of making sure of this.

It looks more like they built with debug config than a commit mistake.

This has always been my rule after seeing an ex-colleague of me leaving one of worst profanity you can say in a test build which was shown to clients during a meeting. I wasn't at the meeting, but I can imagine the situation

Anything bad in there? Didn't see anything...

No, GP's point was that this is a reminder that your debug text may leak, so you don't want to put anything bad in there. Looks like the Vine devs didn't. Good job to them.

Seriously what text? the urls?

Doesn't Apple claim that the point of the review process is to catch these sort of things?

How is a reviewer to know that a debug option is not intended to be there though? It could be deliberately present to help remote support when people report issues. Admittedly the list of features exposed here includes things that you probably don't want the end user messing around with, but I wouldn't expect the reviews to know that - they aren't high level developers running a code review they are QA people tasked with making sure things don't simply fail badly or breach guidelines.

No.

Literally line 1 of the Apple App Store review page:

> "We review all apps submitted to the App Store and Mac App Store to ensure they are reliable, perform as expected, and are free of offensive material."

https://developer.apple.com/app-store/review/

Perhaps having a debug feature is performing as expected? It certainly might be in some cases.

I wouldn't expect a reviewer to reliably know the difference between diagnostic features deliberately present to help with remote support when people have issues and diagnostic features that should only be exposed to the developers.

Presumptions regarding 'performing as expected'. It can't fail!

I think certain developers can skip the review process.

I think its more a case that reviews after your first have a lot less manual intervention, they certainly seem to happen much faster after the initial review.

If that's the case, perhaps Debug builds should be full of "offensive material" so that they are less likely to pass review ;)

Nope

While this incident is quite amusing, I wonder if this could have any negative impact, like unwanted discovery of weaknesses in the API? Otherwise it appears to me that Vine mistakenly shipped a less polished version of their iOS app with no actual negative implications.

I'm really curious as to how this happened. In the app I work on, all of our debug features are wrapped in Preprocessor Macros so they'll only run in debug mode.

Happened to me at my previous company. We had a bunch of #ifdef DEBUG that wrapped non user-facing code. One day someone added DEBUG=1 in debug mode, DEBUG=0 in release mode, which led to the macro check always being true. The change was hidden in the Github PR since it was in our .xcodeproj. Nobody noticed, but even if we did, I'm not sure we would have guessed the actual impact of it.

I think people overuse #ifdef when they should really be using #if.

I'd wager that less than 10% of iOS programmers know that #if works (by treating as false) when the token is not defined.

I've done this sort of thing once, and nearly done it several times more.

The time the product was released like that, it was a Makefile setting a rather important flag using ?=, in a sub-Makefile two includes deep, and because that happened to have always been the first time CFLAGS was set, it worked. Until I added a new flag. (Solution: don't set your Makefile variables like that.)

When I've nearly done it, it's always been on projects that have the fairly standard Debug/Release build config system (via whatever mechanism), and the Release build is the one that gets released. But then you have no config corresponding to Release-and-some-temporary-debug-stuff, which is something you basically always need. But if you manage this by hand, it's too easy to slip up and have some debug stuff end up in the final product. (Solution: have an extra build config, Final/Product/etc., that is what you use when preparing the final build. So if you get it wrong and leave your debug stuff in the Release build, the result never gets further than other team members.)

I'm sorry to be that guy, but if we had more "open" distribution ways for smartphones, something like this wouldn't have happend. Because they would have noticed it early on (to fix it) before anybody else would have.

Now they have to wait before Apple approves their next update.

You can request Apple to do a "fast" review to release an urgent update :)

How does that work if everybody does it? I think Vine is a good position in this, since they're kinda "famous".

You can request it. It doesn't mean the request will be accepted. Unless you are big, can demonstrate an external deadline, or have a bug with nasty consequences (it seems "app crash at launch" is not enough, I got a request denied for that), your request will probably be denied.

Mobile software != web site.

Get over it. It's Apple's platform. Move on...

Why should I get over it and move on? It sucks and I'm going to keep complaining as long as it does.

Linux software also != website but doesn't suffer from these problems. Current mobile software really sucks in pretty much every way and there's nothing more to be said.

> Current mobile software really sucks in pretty much every way and there's nothing more to be said

I don't know what perspective you are coming at this from, but from my experience with non-technical iOS users, installing/managing/removing mobile software in a safe manner is a much better experience than compared to their PC's. My grandparents are fully capable of managing software on their iPhones - if I asked them to do the same on Linux...

If safety for noobs is the rationale then why can't they ship iOS with a deep down hidden switch that allows side-loading?

To keep out the noobs they could make it require a command line tool and display an extra scary warning and have it void the warranty.

I don't see why we should all need to suffer because of the majority's ignorance.

Recent changes to iOS allow side-loading[1]. In answer to your point about the majority's ignorance, I suspect the reasons are varied but if there's a way to circumvent these kind of protections, non-technical users can be coerced into doing so. An example is Facebook disabling the developer console in the browser after users were coerced into using it against themselves[2].

[1] http://bouk.co/blog/sideload-iphone/ [2] http://stackoverflow.com/questions/21692646/how-does-faceboo...

While that might be true in theory, in practice app stores aren't much safer then Linux package managers are.

Just because that is the case, doesn't mean it has to be this way, or that it's OK.

The sad thing is, we all have to accept that mobile App Stores are not a "real software market". Mobile Apps are more like Plugins to some platform controlled by someone else.

Still, i'm sad about this.

This is not sad.

Children dying from starvation is sad. War is sad.

Get over it...

If your App is written in React Native or Cordova then code-push is your friend...

https://github.com/Microsoft/react-native-code-push/

That looks/sounds awesome. Have you run into any negatives using it?

Yeah. JavaScript.

Duh...

Spam.

Coming from Vine this is not surprising

Probably the worse app I've seen on Android. Almost to the point of being unusable

Instagram with videos probably took 95% of their initial users.

Shit happens. Move on.

Guess they hired the wrong iOSers...

Is it really the way to debug your iOS apps, add some features instead of tests?

Like any software project with lots of moving parts, it would be great if one could develop an iOS app in a vacuum, writing tests as required, and using them to guarantee a perfect product.

In reality, that never works. I would expect that these features are actually mostly used by QA or product owners for acceptance testing. The reason they typically exist in my experience is that it can be difficult to trigger the conditions required using other means.

As with every single piece of software in the world, that would be up to the people who implement it.

I just asked if this is a common way to do this, but apparently all the iOS devs felt offended - I will not comment on this.

Thanks for the answer anyway :)

How do you test if a reminder notification really launches on a device after 5 seconds?

In theory, a device should be able to be put into full debug mode where the SDK allows access to basically everything unsandboxed so your test case could actually verify that the notification was correctly delivered.

Reply on news.ycombinator.com