It does not send crash reports to me, but if it crashed without an "oops" dialog popping up, the most likely reason is that it was out of memory. Unfortunately the savers are not good at cleaning up after themselves, because for most of their existence "cleanup" was "SIGTERM".

Most of the X11 ones are pokey. Performance is better with the GL ones. Yes, this is ironic.

When it asks for location, it's really asking for photos (which may have EXIF GPS data in them, which it doesn't use). XAnalogTV will show photos on some of the "channels" as they cycle through.

Hit the disclosure arrow on StarWars (or any of them) to set the text source.

I didn't realise the arrow did anything - just assumed it started the relevant saver rather than bringing up settings for that one (ie no different than clicking anywhere else on the line). If this is normal iOS UI then it is my fault for not knowing better, otherwise I'd suggest an icon more indicative of settings (eg cogs).

I use analytics in my apps to get a good picture of what has been going on. However they won't be useful when you run out of memory since events are saved into a SQLite database for later network dispatch, and that requires (more) memory.

A real hacker would solve the memory leak problem by stunts like saving the brk(2) value before starting a saver, and then restoring it afterwards :-) One of them hierarchical pool allocators would also work and be less brittle. Yes I am aware I'm suggesting more work for you.

I'm told that the way I am using the so-called "disclosure arrow" is, in fact, the Party Line, though I also don't recall having seen them used that way before. I dunno. It's not the most obvious thing, but I can't think of a clearer way, since my first attempt -- select the line, then hit a "Run" or "Options" button up top -- is definitely not the Party Line. And it kinda sucked.

I considered playing malloc games like that (thus my questions about heap tricks over here) but decided that it was probably going to just end up being destabilizing and more trouble than it was worth. If there was a true save/restore that would also smack global variables back to their default state, that would help, but there's not. Putting each of them into their own full process (not thread) is the level of separation they expect, but I think not practical on iOS.

The other option is go through and run each and every hack under a profiler and make sure they actually free all their data at close, but does that sound like fun to you? Because to me it kinda sounds like the other thing.

This method of getting a new process (with both answer comments from 'tc') is amusing, but it probably takes too long and is completely opposed to the Party Line -- calling exit(0) is grounds for rejection, even.

In the Contacts list there are no blue arrows, and tapping on a row takes you to the contact details. Where blue arrows show up, in Favorites, Recents, and Voicemail, tapping a row initiates a call to that person/number.

So XScreenSaver is fully consistent with this "tap the row to activate, tap the blue arrow to get more details" convention.

A more ambitious UI on the iPad would for it to be more like the Settings app, with the list of savers on the left and then the settings for an individual saver showing up on the right--but then it'd need an "Activate" button because tapping a row would just show that saver's settings. There could be a preview view above the settings, though (like the screensavers have in Mac OS X System Preferences)--double-tapping the preview or hitting a "Full Screen" button below it would make it take over the screen... Up to Jaime whether he thinks it'd all be worth the effort, and I wouldn't be surprised if he didn't.

I'm curious why location services need to be enabled in order to draw images from the photo library. Existence of GPS EXIF info (whether used or not) seems to be irrelevant. Is this requirement an Apple thang or specific to XScreensaver?

Thanks for putting the effort to get this out. It is like carrying a little piece of the CHM around in the pocket. I can tell that it will be a lot of fun.

Yeah, it's an Apple thing. That happens automatically when you request an image from the Photo Gallery, presumably on the off chance that one of them has EXIF location data inside it. I suppose they could avoid this warning by stripping the EXIF before returning the raw image to the caller, but they don't.

AirPlay mirroring sends a H.264 stream to an AppleTV. Encoding H.264 in software is Hard. Probably more like "Impossible" with the relatively weak ARM CPUs in iOS devices.

The A5 System-on-Chip used in the iPad 2 and iPhone 4S definitely has a suitable hardware encoder. I'd guess the A4 SoC in the original iPad and iPhone 4 does not. It's not about being blessed, it's about hardware capability. (I'm pretty doubtful about your statement that it's possible for 3rd party apps like Netflix to do it. Last I saw, Netflix simply streams Netflix video directly to your AppleTV, so there's never any point in making an iPhone or iPad play middleman.)

Sorry, I was mentally conflating AirPlay with the ability to connect the device via HDMI to a TV and stream Netflix that way.

Apple's own video app has the ability to send video from the device to the AppleTV via AirPlay, but in light of what you said above, I assume it's only streaming the raw H.264, as opposed to transcoding.

Wait - so you're saying my as-yet-unposted suggestion of producing a large bunch of separate apps translated into Java for Android and renamed "ZawinskiHack" won't be required after all? Damn! I was so sure you'd go for it!

"Before the Law"
A man from the country seeks the law and wishes to gain entry to the law through a doorway. The doorkeeper tells the man that he cannot go through at the present time. The man asks if he can ever go through, and the doorkeeper says that it is possible. The man waits by the door for years, bribing the doorkeeper with everything he has. The doorkeeper accepts the bribes, but tells the man that he accepts them "so that you do not think you have failed to do anything." The man did not attempt to murder or hurt the doorkeeper to gain the law, but waits at the door until he is about to die. Right before his death, he asks the doorkeeper why even though everyone seeks the law, no one else has come in all the years. The doorkeeper answers "No one else could ever be admitted here, since this gate was made only for you. I am now going to shut it."

Apple should ban this
by Rod Begbie
It pretends to be a screensaver but it doesn't work. I think the author should be banned and his apps reviewed MUCH more carefully in the future since I enjoy his blog posts on the subject.

I'm really surprised by how much I like watching it twiddle away on my iPhone in my dock. My only feature request would be to allow some way of letting it cycle through a preferred list, so it could be all demo-mode-y and potentially distract people who come to my desk with questions.

Stupid Apple UI feature update request: Tapping the top of the screen usually jumps to the top of the list. It seems to be the Apple Way, 3rd party support is hit and miss. I don't know how much you want to go back into the tiger den, though. But if you ever find yourself considering releasing an update...

Yeah, I'd like a random-mode too. I'm not sure what the UI for that would look like though. Also, it'd pretty much guarantee that the app would crash eventually, due to memory leaks. The savers aren't leaky while running, but most of them don't clean up when they exit, so if you left it running overnight it would probably have been shot down by morning.

1. Add a "Random" button, either at the top or in a (new) toolbar at the bottom.
2. Tapping the "Random" button makes checkboxes show up on the left side of the list, like in the Mail app after hitting "Edit."
3. Tapping the "Random" button also makes a toolbar show up at the bottom, if it's not already there to hold the "Random" button itself.
4. The bottom toolbar would have a "Check All" button on the left, and an "Activate" button.
5. A "Cancel" button takes the place of the "Random" button.

Usage should be self-evident.

It'd also be nice if it remembered the list of savers that was checked between uses, but that's not as important. Plus there'd need to be a "Clear" or "Uncheck All" button as well, because canceling would no longer clear the list selection.

Yeah, something like that is about how I'd go about it as well. Another consideration: App-wide preferences to control stuff like pixel doubling (because holy hell the 1:1 retina pixels are tiny for certain savers like Squiral). Inside the preference pane you could have a disclosure line that would take you to the list of savers with checkboxes like Lun suggests.

Moot point, of course, unless if it turns out there's an easy way to resource-cap the savers in a spawn/reap cycle like they would need.

The more I play with it, the more I'm impressed with the retina display on my phone. Admittedly, half the time I have to take off my glasses so I can see the damn things, but that's just the slow march towards death I guess.

So, the pixel-doubling thing was a hard call. It uses real pixels in GL mode since all of those were already resolution-independent, and it doesn't hurt performance. But for the X11 hacks, most of the savers look better when using real pixels (e.g. anything that loads pictures or uses images, like Distort or XMatrix) but some of them get hard to see (e.g. the particle systems like Julia or Hopalong). On the other hand, the particle systems look worse if you can see that the pixels are square. Maybe pixel-doubling wants to be a per-hack option.

Sadly, X11 hacks use doubled pixels on Retina iPads because real pixels killed performance: that screen is larger than most desktop displays.

Yeah, I noticed that this morning when I loaded it on my iPad 3 and checked Squiral and was saddened to see the pixels were bigger than my phone. I figured you were doubling them across the board though because yeah - 2048x1536 is a _lot_ of pixels. But yeah, it's probably a per-hack decision. Although I could see a case being made for an app-wide configuration screen for stuff like pixel doubling and Show FPS and maybe some sort of list filtering options. I don't suppose there's any existing hack metadata that could be used to generate groups? i.e. "particle" "fractal" "openGL" "trippy" "math", etc. That could be a useful crowdsourced project if there isn't any.

All that said, I forget which of the Moire-style ones I looked at this morning which was absolutely _beautiful_ once it finished rendering out the retina pixels, that would be a shame to force into a doubled mode.

Although I'm sure at least the 3Gs were available well before 4.2, it may be that Apple dropped support for mine at that release...I don't see much of iTunes since I live in linuxland.

Anyway, build target seemed like the most likely reason - but I thought I'd ask since previously, if an app was visible to me in the store, the usual reasons for non-support were lack of a camera and/or built-in mic. I'm pretty confident I hadn't seen that Very Capitalized Message before.

(This was a gift from a well-intentioned family member who knew I didn't have an mp3 player anymore, but didn't quite grok why. Not that I minded. In 2009 it was a much shinier toy than my Android.)

To be honest, I'm actually impressed this ever got approved. At the very least, I would have expected them to keep finding screensavers that crashed or ran poorly, and forced you to remove them and resubmit.

Huzzah! Congrats, man. That was way more problematic than it ever should be.

In addition to the feedback above, I've noticed that the app's UI handles being in landscape modes just fine, but triggers the screensavers in portrait mode. I use my iPad in portrait mode a lot and the sideways BSODs are kind of disconcerting. :-)

Also Bouncing Cows and Flying Toasters occassionally crash with "buffer data not a pointer" but most other times work.

I'm loving this, thanks for putting up with all the bull excrement to get it pushed through the system.

Apple ][ got the "new iPad" to reboot, after I ran though a tasting menu of about 2/3rds of all the savers. Presumably Apple or you can see those crashes. My guess would be iOS not dealing well with GPU resource pressure. Or maybe it was judged "too meta" and kicked me out...

So many of the slow savers are fixed! Woo-hoo! But many of them are like Spotlight - still pretty slow, jerky appearance, load high though not 100% as before. Others in this category: Anemotaxis, Apple ][, Blaster, Blocktube, Bouboule...; hope that's enough to suggest some underlying commonality.