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.
========================================================================== */
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.
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
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.
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.
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."
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.
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.
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'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 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.
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...
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].
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.
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.
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.
