How Apple hides new functionality in iOS: isYoMamaWearsCombatBootsActive | Hacker News Reader

How Apple hides new functionality in iOS: isYoMamaWearsCombatBootsActive

github.com

200 pointsdoh115 comments

BeOS had is_computer_on() and is_computer_on_fire() APIs:

  int32 is_computer_on(void)

  Returns 1 if the computer is on. If the computer isn't on, the value returned
  by this function is undefined.

  double is_computer_on_fire(void)

  Returns the temperature of the motherboard if the computer is currently on
  fire. If the computer isn't on fire, the function returns some other value.

http://www.tycomsystems.com/beos/bebook/the%20kernel%20kit/s...

Another Good one from Objective C:

2012-08-31 00:26:19.773 App[1676:907] * -[__NSCFCalendar components:fromDate:toDate:options:]: fromDate cannot be nil

I mean really, what do you think that operation is supposed to mean with a nil fromDate?

An exception has been avoided for now.

A few of these errors are going to be reported with this complaint, then further violations will simply silently do whatever random thing results from the nil.

Here is the backtrace where this occurred this time (some frames may be missing due to compiler optimizations):

Without getting into the IT-sexism-blah-blah, 'your mother wears combat boots' isn't just a folksy turn of phrase: it's a fifties-era impugnment of lesbianism. So unless you want to sound a lot more Republican than you were probably intending, you should probably stop wondering why you don't have more female friends, coworkers, and partners. And by the way, a foot in the mouth is so gay.

Here's another easter egg - it's a sarcastic warning if you try to perform date operations on a nil date:

" -[__NSCFCalendar components:fromDate:]: date cannot be nil

I mean really, what do you think that operation is supposed to mean with a nil date?

An exception has been avoided for now.

A few of these errors are going to be reported with this complaint, then further violations will simply silently do whatever random thing results from the nil. Here is the backtrace where this occurred this time (some frames may be missing due to compiler optimizations):"

Source: http://stackoverflow.com/questions/12505833/what-kind-of-sar...

I don't understand, what does this function do? Is it a reference to something? Or just a simple easter egg?

Apple ships iOS beta builds before announcing new hardware. They obviously don't want to leak information about new functionality like HDR support too early. So they use a special string "YoMamaWears..." meaning of which is known only to people in the appropriate team. Then, when iPhone 5s is finally released, they easily find-and-replace the obfuscated methods with proper identifiers.

It does look like an HDR placeholder, or one hell of a coincidence.

From `AVCaptureFigVideoDevice.h`

    -- (BOOL)isYoMamaWearsFancyGlasses;
    -- (void)setYoMamaWearsFancyGlassesDetectionEnabled:(BOOL)arg1;
    -- (BOOL)isYoMamaWearsFancyGlassesDetectionEnabled;
    -- (BOOL)isYoMamaWearsFancyGlassesDetectionSupported;
    +- (BOOL)isHighDynamicRangeScene;
    +- (void)setHighDynamicRangeSceneDetectionEnabled:(BOOL)arg1;
    +- (BOOL)isHighDynamicRangeSceneDetectionEnabled;
    +- (BOOL)isHighDynamicRangeSceneDetectionSupported;

It's funny because "Fig" was supposed to be replaced by CM or CoreMedia at some point but it was so integrated into the code that it never happened. So here we have a rare case of double export obsfucation.

They’re masking new features with ”creative” variable/method names.

Oooh, I see. Thanks.

It's a feature flag, but it's one that user's don't have easy access to. Pretty much every big software company does this, because it's a very effective way of testing new code. I know MS, Amazon, and Google all have tooling designed to facilitate just this sort of thing.

Let's say you've rewritten core parts of some system, but you've also added new features that didn't exist before. Often times such changes are inextricably bound together. On the one hand you may want some users to test out the new code to make sure it works correctly, but on the other hand the new features you've added may not be fully "baked" so you want to restrict their use. That's where secret feature flags come in.

  - (BOOL)yoMamaWearsCombatBootsAutomaticallyWhenAvailable;

priceless!

I wonder whether Apple will decide to change their strategy of aggressively guarding upcoming products before they are launched, under Cook's leadership.

I was following a couple of 'rumor' blogs prior to the iPhone launches earlier this week and I believe they had managed to 'leak' and publish details on the iPhone 5C and 5S pretty spot on.

EDIT: rather than referring to the variable names in the OP, I'm referring to the more overarching strategy of guarding the features of their to-be-launched products.

I doubt it, that's more of a cultural thing instilled by Jobs, it's sort of entrenched as the "Apple way" of doing things. Big Cultural changes in an org typically come about when things are going badly.

The leaking is going to be hard to stop because Apple largely outsources its manufacturing and is now closely watched (compared to pre-ipod and iphone days). It's hard to enforce secrecy along the entire process when the process is run by third parties and spread around the world.

I wondered the same thing, especially after Phil Schiller's comment: "a few of you probably saw some shots on the Web...and that's cool!"

Also isYoMamaWearsFancyGlassesDetectionEnabled

if you ever investigate the call stacks when there is a crash in their stuff from wrong parameters you can find all kinds of weird names. I'm still wondering what the purple coloured port is :)

"Purple" was one of the code names for the first iPhone - http://allthingsd.com/20120803/apples-scott-forstall-on-how-...

I've seen PurpleEventCallback show up in different stacks.

The method's name is actually "isYoMamaWearsCombatBootsSupported". That being said, it's nice to see developers at big companies having fun.

Fancy Glasses = iPhone5S Combat Boots = iPhone5C ???

Must be a tradition, the old Newton had some interesting names for functions in its API dealing with horses.

Well, that Myriam dude's going to be upset.

I think it is a nice way to do it. :)

Yo Mama thinks it's a nice way to do it, too!

I definitely love those kind of easter eggs.

There are also similar methods in the Android SDK:

UserManager.isUserAGoat() link: http://developer.android.com/reference/android/os/UserManage...

Log.wtf() link: http://developer.android.com/reference/android/util/Log.html..., java.lang.Throwable)

AdapterViewFlipper.fyiWillBeAdvancedByHostKThx() link: http://developer.android.com/reference/android/widget/Adapte...

Not to forget the gravity constants of the Death Star and The Island, defined by the SensorMananger.

http://developer.android.com/reference/android/hardware/Sens...

I wonder if they seriously discussed internally that gravity constants for other planets were needed in case Android devices would be used in space travel.

Well, there are several on the ISS.

There's been balmy little bits of stuff like this all the way through OSX and iOS for ages, though maybe not quite as flippant.

Every Mac has the kernel extension "Dont Steal Mac OS X.kext" for example, which loads into RAM a short poem.

    There once was was a user that whined 
    his existing OS was so blind, 
    he'd do better to pirate 
    an OS that ran great 
    but found his hardware declined. 
    Please don't steal Mac OS! 
    Really, that's way uncool.

I wonder if this has (or had had) some legal significance.

I remember some issues with the Apple II rom being copied and that they had to add a "Copyright Apple" or something similar to the binary data.

They added stuff to the Mac ROMs in reaction to the copying of Apple II ROMs. See http://www.folklore.org/StoryView.py?story=Stolen_From_Apple...

The idea is that this poem is copyrighted as a creative work, and therefore Apple can control its distribution. The actual key contains a copyright message after the poem.

If I recall correctly, they added a watermark to the ROM. The concern was that as adversary could modify the code to make it difficult to prove that it was actually a copy. The watermark was a hidden section of the code which could be executed to demonstrate that the code did in fact originate from Apple.

If anyone can confirm/deny this, please do.

Every Maccard on the planet seems to think pirating OS X is an oh so terrible thing to do (to the point that parent post is bringing up poems about it like its a cute, non-weird thing). At the same time pirating everything else on the planet seemingly is OK.

I've never understood the rationale behind this.

Keep in mind I'm a software developer myself and run strictly non-pirated software, and open-source as much as possible. You could never make me replace a Linux desktop with a limited OS X experience, and I see no reason what so ever to put in the effort to pirate it.

But why is it worse to pirate a OS with bad hardware-support out of the box than pirating... say Microsoft Office? I'm just curious what's up with that.

As an Android developer I had many discussions with Apple users/devs but I never heard anyone say something like that.

In my experience Mac users tend to be quite scrupulous about paying for their software.

Apart from their Adobe suites... (In my experience).

Note that I don't have any pirated software on my machine. Running Debian here.

With OS X there's no license key you need to enter, they have a poem instead asking you not to steal it. That's a nice thing, rather than assuming you're going to steal it they have a poem to jokingly ask you otherwise.

Sure, no license key, except for the key used to decrypt protected binaries only on authorized hardware.

There is a license "key", it's the whole computer.

What are protected binaries? This is something I've not heard of OSX having.

As far as I know, as long as all the hardware is stuff OSX has drivers for (and you generate a DSDT to describe that hardware) then you don't need any special "authorization." You just put in the OSX installer USB/DVD and it works.

It's mentioned on the page 0x0 linked to — http://en.wikipedia.org/wiki/Apple%E2%80%93Intel_architectur...

> A Mac OS X system which is missing this extension, or a system where the extension has determined it's not running on Apple hardware, will be missing this decryption capability, and as a result will not be able to run the Apple-restricted binaries Dock, Finder, loginwindow, SystemUIServer, mds, ATSServer, backupd, fontd, translate, or translated.

Certain apps, such as the Finder and the SystemUIServer, are encrypted and this kernel extension will only decrypt the executable pages if it considers your Mac to be genuine (consulting the TPM, I believe).

The TPM was used briefly at the beginning of the Intel mac days, but hasn't been used since. The decryption is now done through dsmos.kext in software.

http://osxbook.com/book/bonus/chapter10/tpm/

OSX does have 'protected binaries', which refers to binaries that use encrypted pages[1] that require decryption via an anti-piracy kernel extension (Don't Steal Mac OS.kext). This extension can check that you're running on Apple hardware by checking with the System Management Controller(SMC), which is Mac-specific[2].

In the old days (10.4), hackintosh systems would patch the protected binaries to remove the page encryption/decryption. Over time kernel extensions were developed to replace the functionality of Don't Steal Mac OS.kext (dsmos.kext or AppleDecrypt.kext) without the hardware checks.

The reason you no longer need either of these extensions is because a kernel extension called FakeSMC.kext was developed, which emulates as much of the functionality of the SMC as possible. This includes thermal and fan monitoring as well as the decryption key storage.

In a modern hackintosh setup, you make use of EFI emulation (inc. DSDT support) included in the bootloader (a boot-132 derivative, most likely Chameleon) and the pre-boot loading of emulator kernel extensions like FakeSMC.kext.

[1]: http://www.osxbook.com/book/bonus/chapter7/binaryprotection/ [2]: http://osxbook.com/book/bonus/chapter7/tpmdrmmyth/

I don't get why people are still whining about this in 2013. Is it really that unreasonable for an OS manufacturer to restrict the devices on which it can be installed? I write firmware for a specific known hardware platform; do I really want the pain of people using it on an Arduino? The appeal of OSX is that it just works, and works beautifully most of the time. Opening it up to all the devices dilutes the main thing it has going for it.

Sometimes there is freedom in restriction.

I don't get the whining either; I was just dispelling a myth.

That said, I don't find your arguments compelling; there's a difference between supporting and just not artificially preventing the software from running, and I don't see how doing the latter would make OSX stop "just working" on officially supported machines.

In fact, it's not like they don't anyway, and I don't see how have Hackintoshes diluted the experience of OSX on an Apple machine.

If Apple sold it as an operating system, they'd have to deal with a nightmare of drivers. As it stands one disk can cover almost every Mac ever made, and they're content with that.

Sure, but they wouldn't have to sell it as an operating system just to remove the artificial restrictions. They could still support only their machines, and just not encrypt the binaries and all that nonsense.

But I'm not saying they should, as I said, I don't really care. I'm just saying that just because they don't want to support other machines, that doesn't mean they have to purposely block them.

I mean, Asus doesn't support Linux on their motherboards either, but they don't have BIOS checks verifying that the OS is supported and refusing to boot if it isn't; they just tell you "you're on your own".

> they don't have BIOS checks verifying that the OS is supported and refusing to boot if it isn't

In fact the machines they're selling now almost certainly do have precisely this. It's called 'secure boot', and caused a lot of controversy. The major Linux distributions work because they've managed to get themselves signed with the appropriate key so the BIOS accepts them, but if you want to put a more niche distribution on there, you probably have to disable that check in the BIOS.

No, Secure Boot doesn't check if the OS is supported, it just checks if it's digitally signed, and that the signature is valid.

And you don't even have to disable the check if you want to use an unsigned distribution: most (all?) implementations allow the user to load her/his own public key to verify the signature against.

While we should worry about its impact - particularly in certain implementations - it's really not even close.

> Is it really that unreasonable for an OS manufacturer to restrict the devices on which it can be installed?

Yes, it is. If I pay for a product, it's my prerogative to use it in any way I please. Copyright grants a monopoly on distribution, not on controlling post-purchase usage of the product.

It's one thing to say "we only officially support installation of this product on this list of devices, and can't guarantee it will work on other devices", but inserting artificial restrictions into the product that prevent people from even trying to do officially unsupported things with the product, at their own initiative and at their own risk, is something there really isn't any justification for.

> do I really want the pain of people using it on an Arduino?

What pain? How does it even concern you if people are installing your firmware onto an Arduino, provided that they have legitimate copies of it?

> Opening it up to all the devices dilutes the main thing it has going for it.

Obviously, not installing OSX on other devices is what dilutes the "main thing it has going for it" for those people who have chosen to install OSX on other devices. Are you seriously trying to tell people that their personal preferences are objectively wrong?

> Sometimes there is freedom in restriction.

Straight out of Orwell.

They also have it (somewhat) tied to the hardware, which reduces the threat of piracy in the first place.

I'm not sure how you came to that conclusion. From your tone I suspect you're simply biased against Macs.

What is a Maccard? I've never heard anyone say that pirating OS X was more ok than any other kind of piracy.

I thought it was Mactard.

Then you read it again and see that nowhere in that post was the phrase "tard" anywhere to be seen.

Maccard = a word for a mac-user person thingie. There's nothing derogative about that.

If people read it as you did though, that might explain the downvotes.

How about "Mac user"? Avoids confusion...

Or perhaps Mactart for those that like flashing their devices publicly.

Maccard = Mac user.

And the attitude I've seen (especially in the OSX 86 community) is that general piracy is completely OK, but you have to buy OS X from Apple, otherwise you are doing something super-duper wrong. Then they move on to pirate Photoshop.

It's a mind-bending sort of ethics, and I was curious about what the reasoning behind it was.

I've never once come across this. I've come across Mac people that pirate stuff, and Mac people who don't and think that's wrong. That's fine, different people are entitled to their own opinions. But never once I have a come across anyone suggest that pirating other stuff is OK, but not Apple software.

That's not the mac using community as a whole then, is it. It's exactly the same a saying that all user of open source software are cheap because they don't want to pay for software. An entirely ridiculous statement that I'm sure you'll find abhorrent for many different reasons.

You know 1 person doesn't represent a community right?

Sample size of one seems sufficient to establish a general pattern.

By OSX 86 community do you mean Hackintosh users?

If so, Hackintoshes are, from Apple's point of view, piracy anyway. Apple makes no money on the OS (which they sell for a few dollars) and all their money from the hardware the Hackintosh user is avoiding buying. So whatever ethics are involved are already in a dubious state.

If you mean general Mac users, then, as I and others have said, there isn't a prevalent attitude of condoning piracy (everyone I know who uses Photoshop/Illustrator/InDesign has paid for it).

I guess it's something like a Wintard/Lintard - only with more disposable income.

Who said anything about tards? I said Maccard and there is nothing derogative about it. Jeez.

>Every Maccard on the planet seems to think pirating OS X is an oh so terrible thing to do

First, who are those "Maccards" you are reffering to? Perhaps you meant to say "OS X user" or "persons who likes Apple stuff".

Second, a lot of us OS X user could not care less if you pirated OS X or not. Matter of fact, I know several people with genuine Macs that also run a Hackintosh (and I experimented with one a while ago).

>(to the point that parent post is bringing up poems about it like its a cute, non-weird thing).

The poem is placed by Apple developers, inside the OS X internels. IIRC, it's loaded in a .kext (a kernel extension). That's cute, especially it being a flippant poem and not some 20 page long legal text. In essense, it's a small easter egg.

It's not like random Apple users write poems about not pirating OS X, which seems to be your impression.

>At the same time pirating everything else on the planet seemingly is OK.

"Maccards think pirating OS X is very bad" (wrong) "At the same time pirating everything else on the planet seemingly is OK" (wrong again).

Even if "Maccards" (sic) thought that pirating OS X is bad, who told you it's the same persons that think pirating everything else is OK?

>I've never understood the rationale behind this.

The problem might be that what you believe goes on is not happening in the first place.

I can definitely understand that, having pulled and Android app from the store because of piracy recently. (in app purchase is really hard to circumvent by pirates, but apps where you pay upfront are pirated like crazy)

How does pulling the app from the store benefit you?

By re-releasing it again as a free app with in-app purchase (which is very hard to pirate)

You can't change a paid app to free on the Google Play store. All you can do is to pull it, and submit it again.

Did you find that your revenues increased when you switched to IAP?

I already had an IAP version in the store all the time and additionally the paid one (I honestly do not know why I thought that this was a good idea) - all I actually did was to pull to paid one.

It seems to have increased the sales for less than 10% in my case, but since I did this only a few days ago, I cannot say with confidence that it had anything to do with the switch.

But it did reduce confusion about the product itself and therefore support emails. (just the fact that there were 2 ways to get the full featured app was confusing to many - but this pro only exists because my own stupidity)

Long term I hope (it may never happen) that less people upload and therefore download pirated apks, because those versions are often very outdated, and some downloads out there are even broken because of that, causing additional support requests and bad reviews. (I rely heavily on Facebooks APIs, which change quite frequently)

If someone asked me if it was a good idea to pull an app that has been out there for a year or longer (with 100.000+ downloads) and resubmit it again I would definitely say no, because that also means that you basically start from zero again - from 1000+ downloads per day down to 10.

I don't know how the rankings in the Google Play store are created, but it seems to me that being around for a long time favors your ranking and downloads heavily.

That .kext is also responsible for verifying some sort of signature in a hardware chip only present on genuine macs. See http://en.wikipedia.org/wiki/Apple%E2%80%93Intel_architectur...

This used to be the case, but no longer is; Apple stopped using the TPM in Intel macs shortly after they launched[1] and have not brought it back since.

DSMOS.kext has another function, however; it is involved in Apple's binary protection scheme[2] for certain OSX binaries. Essentially, OSX ships with certain important binaries (such as loginwindow, SystemUIServer, Finder, and Dock) that have certain vm pages encrypted. Decrypting these pages for use requires DSMOS.kext.

[1]: http://osxbook.com/book/bonus/chapter10/tpm/ [2]: http://www.osxbook.com/book/bonus/chapter7/binaryprotection/

Yes, and before it will perform the decryption, it needs the correct "SmcDeviceKey", so I think my point still stands :)

Yea, they eschew the DRM-only TPM part to store the keys in the SMC, which does a whole host of things and doesn't protect the keys. I suppose you were sufficiently vague ;)

There's just an outstanding myth that Macs still use TPM...

Didn't Jobs say "Great Artists Steal."?

Users who are artists must heed these wise words.

All Hail the Cult Leader.

As for this "poem", I've seen better from kids in elementary school. This speaks to the creative aptitude of Apple's kernel engineers. Certainly not the strongpoint of their workforce.

What sort of royalties or up-front payments did CMU get for letting Apple use their kernel?

It's actually very nifty - if you use a "secret"(obscure) key or checksum to check authenticity of hardware, then it still could be legally duplicated as nothing before DMCA was passed would prohibit that. If you use a scrappy poem as that key/token... then it's clearly copyrightable, and its duplication by some other manufacturer can be restricted with ages-old laws.

Do you have a citation for the cases where Apple has successfully argued used this in court against some other party who was pirating OSX?

It's only "nifty" until it's put to the test and fails in court. It's "effective" as a way to protect software only in the minds of some Apple engineers; but a judge might not see it that way. There's no precedent to assure anyone that it would work. If there were, I suspect we'd see it in widespread use. Or maybe Apple has tried to patent it?

Perhaps the DMCA exists because "nifty" gimmicks like this one cannot be relied on?

Nice try.

Reminds me of VAX chips during the Cold War. They had "When you care enough to steal the best etched on the chip in Cyrillic.

These are not the same, as these are left in production. The code names in the iOS binaries were later replaced by their real functionality as it no longer needed to be secret.

I see, so this is some kind of obfuscation. Thanks for the information.

There is also WTF in WebKit source.

It stands for Web Template Framework, but it's funny it appears all the time in crash reports:

http://google.com/search?q=wtf+webkit+crash

For example:

    Thread 2 name:  WebThread
    Thread 2 Crashed:
    0   JavaScriptCore                  0x32a97d46 WTF::StringImpl::hash() const + 42
    1   JavaScriptCore                  0x32a97c6a WTF::HashTable<WTF::StringImpl*, WTF::StringImpl*, WTF::IdentityExtractor<WTF::StringImpl*>, WTF::StringHash, WTF::HashTraits<WTF::StringImpl*>, WTF::HashTraits<WTF::StringImpl*> >::lookupForWriting(WTF::StringImpl* const&) + 18
    2   JavaScriptCore                  0x32a9b028 std::pair<WTF::HashTableIterator<WTF::StringImpl*, WTF::StringImpl*, WTF::IdentityExtractor<WTF::StringImpl*>, WTF::StringHash, WTF::HashTraits<WTF::StringImpl*>, WTF::HashTraits<WTF::StringImpl*> >, bool> WTF::HashTable<WTF::StringImpl*, WTF::StringImpl*, WTF::IdentityExtractor<WTF::StringImpl*>, WTF::StringHash, WTF::HashTraits<WTF::StringImpl*>, WTF::HashTraits<WTF::StringImpl*> >::add<WTF::StringImpl*, WTF::StringImpl*, WTF::IdentityHashTranslator<WTF::StringImpl*, WTF::StringImpl*, WTF::StringHash> >(WTF::StringImpl* const&, WTF::StringImpl* const&) + 448
    3   JavaScriptCore                  0x32a9ae30 WTF::AtomicString::addSlowCase(WTF::StringImpl*) + 96
    4   WebCore                         0x31bade0c WebCore::AtomicHTMLToken::initializeAttributes(WTF::Vector<WebCore::HTMLToken::Attribute, 10ul> const&) + 232

You can also boot an iPhone in WTF mode, though I'm not entirely sure anybody outside of Apple knows what it does.

http://theiphonewiki.com/wiki/WTF

I love how wtf, in Androidland, stands for "What a Terrible Failure"

I'd be interested to see the "easter eggs" that drain the battery within 12 hours.

12 hours is a good battery life is it not? Admittedly, the iOS7 BETAs have cut my own down to the point where I have to make sure my phone is on 100% before a 4-5 hour night out so I know I'll have battery to use it by the end of the night.

Although I suspect that'll be fixed post-beta

It means you can trash your phone. It's worthless. The iTemple will welcome you for your next iPhone purchase - if you accept not to indulge in any iBlasphemy.

The 12 hours are in stand-by (no screen/wifi/bluetooth/phone usage/message usage whatsoever).

And I had 3-4 days before the "upgrade".

In my case I just "upgraded" the OS on my 3GS to the current state: v. 3.1.6 (after having refrained from doing so for a very very long time - precisely because I had read about the drastic battery drainage at the time). So no beta software was involved.

EDIT: Here's an example of a thread in the "support" forum: https://discussions.apple.com/thread/4325659?start=15&tstart... (I have tried every "solution" I could find on the net - nothing has fixed this. Which means we must assume this is strategy, not temporary bugs.)

It's called a BETA for a reason :-) The 3GS was released in 2009 which is quite a long time ago in technology terms so to expect it to be able to handle a more CPU-intensive update easily is a bit silly.

Did you even read?

> It's called a BETA for a reason

My "upgrade" was NOT BETA.

> The 3GS was released in 2009 which is quite a long time ago in technology terms so to expect it to be able to handle a more CPU-intensive update easily is a bit silly.

It worked perfectly BEFORE the "upgrade" (batter life: 3-4 days!), why would it not AFTER the "upgrade"? I mean, the "upgrade" was SPECIFICALLY coded for the 3GS. If it's "bricked" after the "upgrade", that says it all.

You have to be a sheep if you accept Apple "bricking" your device just like that.

EDIT: Ok, seems like I have enraged the iGods with some critical thinking.

No offence, but what does that have to do with iOS7's battery life? It seems you just wanted to start screaming about how everyone that buys Apple is a 'sheep' and use some terrible puns. You do tend to get downvoted if you don't contribute anything to the conversation.

You said my 'phone is useless now' which is completely incorrect. I wouldn't expect it to have perfect battery life in a BETA...

> what does that have to do with iOS7's battery life?

It has to do with Apple's apparent general battery strategy. The devaluing of devices sold as "upgrade" was done a few years back, and as I've mentioned above, it's still done today.

> You do tend to get downvoted if you don't contribute anything to the conversation.

The contribution here is: DO NOT "UPGRADE", UNLESS you are ok with being forced to buy a new phone BEFORE your "old" phone ceases to fulfill your actual/real needs! I hope this is now clear enough.

If this warning is NOT valuable, then I'm clearly on the wrong site here.

> You said my 'phone is useless now' which is completely incorrect.

Of course it is useless as a mobile phone. It's supposed to be a mobile phone (for travel etc.). So, if I have to keep it plugged in just to do calls, WiFi and bluetooth, then it's called a landline phone and I have to buy a new mobile phone.

> I wouldn't expect it to have perfect battery life in a BETA...

Why do you keep talking about "beta". As I've said in the downvoted posts already (twice): It was a NORMAL UPGRADE downloaded because iTunes kept bugging me with it. NO BETA HERE.

I've said it once and I'll say it again: This has nothing to do with the original topic. I posted about iOS7s battery life in the BETA and you started getting agitated about an iPhone 3gs upgrade (not iOS7...)

The phone is 4 years old. That's quite a long lifespan for a phone and if you're angry because the battery life has depleted, you obviously don't have an idea about how batteries work. Of course a new update is going to have an impact on the battery. Since it requires more CPU/Memory (which the iPhone 3gs is severely lacking in) the battery takes a hit.

>Why do you keep talking about "beta". As I've said in the downvoted posts already (twice): It was a NORMAL UPGRADE downloaded because iTunes kept bugging me with it. NO BETA HERE.

Then why are you talking about it? We are talking about the iOS7 BETA. Not iOS3.

>Of course it is useless as a mobile phone. It's supposed to be a mobile phone (for travel etc.). So, if I have to keep it plugged in just to do calls, WiFi and bluetooth, then it's called a landline phone and I have to buy a new mobile phone.

You said my phone. Not yours. My phone acts perfectly as a mobile device :)

>The contribution here is: DO NOT "UPGRADE", UNLESS you are ok with being forced to buy a new phone BEFORE your "old" phone ceases to fulfill your actual/real needs! I hope this is now clear enough.

Don't upgrade if you don't want to. Nobody is forcing you to buddy. I wouldn't expect an old computer to handle all the new games perfectly at full resolution

>It has to do with Apple's apparent general battery strategy. The devaluing of devices sold as "upgrade" was done a few years back, and as I've mentioned above, it's still done today.

Which is nothing to do with iOS7

Blame it on the "iGods" if you want, but your ridiculous all-caps whinging is what earned this a down-vote from me.

Did your device get bricked? That sucks, it's never fun. Did you take it in to get it unbricked? Everyone I know that's had hardware trouble like that has had their phone either fixed or, surprisingly, replaced. If the OS is designed to run on your phone and it doesn't, that's a defect, and you're entitled to a fix.

If you mean standby time, it is absolutely horrible.

That is exactly what I mean.

My Nexus 4 lasts about 4 hours of usage, about 10 hours of standby time. I really wish it had a replaceable battery. Phones these days just don't last very long.

Is that a recent beta? I actually had a day and a bit of battery life recently on the last beta. https://twitter.com/nicholassmith/status/369579656791732224/...

I was just talking about BETAs in general. The one I have at the moment is a bit better but I tend to charge my phone at work so I don't usually notice

Fair enough, the early ones were awful for battery. B1 turned my iPhone 5 into a hand warmer and meant I couldn't be away from a plug for more than 4 hours.

Oh yeah, I remember unplugging my phone at 100% then a few hours later having the 10% warning flash up. Luckily, it's at least better than that.

12 hours would be pretty bad for me. My 4S purchased on launch day (so nearly two years old now) gets unplugged at about 8AM, stays unplugged all day, and usually gets plugged in at 11PM with ~50% battery remaining.

I've noticed my battery life as more to do with how many notifications I get over any other usage.

Reply on news.ycombinator.com