…the company has just received a patent on what has become a common method of giving presents — a system for selecting digital gifts such as movies, music or e-books, sending an electronic notification to a recipient, and allowing them to download the gift.
I imagine there’s more prior art on this than on the one-click patent. Or are they only claiming the idea of letting the recipient reject the gift?
In the last five years, LLVM has evolved from an academic project to the universal back-end of C, C++, and Objective C compilers. The key to its success is its performance and adaptability, both of which derive from its unique design and implementation.
To me, this is some of the best work Apple is doing right now.
It may be that you really want to stop Xcode from playing a “Basso” sound when a test fails but in general I find most of the default settings to be fine. The real power of behaviors comes when you realise that you are not limited to triggering them in response to an event (such as “Testing fails”).
If you click the “+” button at the bottom of the Behaviors preference pane you can add your own custom settings which can then be assigned a keyboard shortcut. This allows you to become much more task oriented. The basic approach is to define a custom behavior for each key task you perform (editing, debugging, NIB design, etc.). The keyboard shortcuts then provide a quick way to switch between tasks and always ensure that Xcode is configured just the way you want it.
See also: How to Make Xcode’s UI Work for You.
Discussing that in the office, we just concluded that we must have been sent the boiler-plate response to all non-compliances with the particular referenced section of the App Review Guidelines, and that it really didn’t matter (to Apple) whether the response was actually accurate or not.
Let’s start by simplifying the problem. Your phone (and your Wii controller, I believe) have three accelerometers oriented at right angles to one another. We’re going to study the behavior of just one accelerometer. Once you understand the behavior of one, extending it to three is easy.
I thought I’d leave an open question:
1) Do you know of an app whose future is put in jeopardy by sandboxing? (Ideally: an app that you wrote)
2) Is it so bad that there’s a real risk that the app will be frozen in its pre-sandboxed state?
The save fails because the underlying SQLite library created temporary files on behalf of Core Data. You may have seen a file like this. Usually this file has the suffix “-journal”. When you activate sandboxing your application is only are allowed to read and write to the store file itself and not to the “-journal” file. This explains why the save of the context fails.
Sandboxing is incompatible with the default way of saving Core Data files. Developers filed bugs about this as soon as sandboxing was announced last June, but there has been no change. The workaround is to turn off database journaling, which puts your data at risk in the event of a crash or power failure.
Rockstar is a special kind of company. Because it doesn’t actually make anything, it can’t be countersued in patent cases. That wouldn’t be the case with Apple or Microsoft if they had kept the patents for themselves. And because it’s independent, it can antagonize its owners’ partners and customers in ways that its owner companies could not.
[…]
When the Rockstar Bidco group purchased Nortel’s patents, the U.S. Department of Justice took a look at the deal, as part of a broader investigation into several large technology patent sales. The DoJ was concerned that patent attacks might somehow be used to knock Rockstar’s competitors out of the smartphone or tablet market. But in February, the DoJ closed its investigation, in part because Microsoft and Apple had promised to license many of their core wireless patents under reasonable terms to anyone who needed them.
But the new company — Rockstar Consortium — isn’t bound by the promises that its member companies made, according to Veschi. “We are separate,” he says. “That does not apply to us.”
Collecting patents defensively is understandable; forming a patent troll is evil.
We first heard from Apple about this decision two days ago, and we’ve been discussing the pending removal with them since then. However, we still do not yet have a clear answer on why Apple has chosen to remove Airfoil Speakers Touch.
It’s been in the store since 2009, and the version being rejected now was accepted back in April.
Update (2012-05-25): John Gruber:
Apple doesn’t provide APIs for apps to serve as AirPlay receivers. Rogue Amoeba backwards-engineered the protocol, and coded their own iOS AirPlay receiver implementation using (they claim, and I have no reason to doubt them) only public APIs. I think the bottom line is that Apple is saying that apps are not allowed to act as AirPlay receivers on iOS, but there’s no App Store guideline that explicitly forbids that.
Part of the problem is that Apple is not saying anything except that the app is rejected. There are apparently 5–6 other AirPlay receivers that have been rejected, yet the rules haven’t been updated to forbid this, and Apple has not given Rogue Amoeba any explanation.
Update (2012-05-29): Kafasis has posted a follow-up:
As we’ve stated, to the best of our knowledge we’ve implemented Airfoil Speakers Touch using only publicly-available APIs, and in full accordance with the developer agreement. We’ve continually asked what non-public APIs they believe we’re using and have received no response.
Indeed, there seems to be something of a communications problem with Apple, as we haven’t heard from them since May 23rd. Apple apparently did have time to contact The Verge about this issue on May 25th, however, repeating their claim that we’re using non-public APIs.
First Apple removes the app from the store, then it gives the developer an explanation that’s transparently false, then talks to the media—still without telling the developer the real reason for the rejection.
Unfortunately, both the App Store and the review process are entirely controlled by Apple, so there’s not a lot else we can do at the moment. We’re definitely concerned Apple may just silently stonewall on this, so we’ll keep discussing it here.
Update (2012-06-06): It’s back in the App Store, without the Enhanced Audio Receiving feature:
Regardless, Apple is using the authority they provide themselves in the guidelines and program license agreement to remove apps they don’t like. Specifically, they cited a provision in the App Store Review Guidelines which allows them to reject apps “for any content or behavior [they] believe is over the line”. That’s certainly disappointing, and frustrating, but it’s the nature of the system Apple has created.
If nothing else, we’re gratified to at least have come to an understanding that we didn’t violate the guidelines – Apple simply doesn’t want us providing this functionality in the App Store. Ultimately, if Apple doesn’t want it, we can’t provide it and users can’t have it.
Update (2012-06-08): Phil Schiller:
The story as I understand it is simple, and not accurately recounted on Rogue Amoeba’s website. Rogue Amoeba’s app added a feature that accessed encrypted AirPlay audio streams without using approved APIs or a proper license and in violation of Apple’s agreements.
While Apple licenses the ability for hardware manufacturers to play AirPlay audio, there is no such licensing program for software. When we inquired as to the possibility of this type of licensing being available for software manufacturers in the future, we were informed that it was unlikely. […] We steadfastly stand by our statement that Airfoil Speakers Touch violated no part of our agreements with Apple.
Apple is within its rights to reject whichever applications it chooses. However, it’s scummy that the official reason was the nebulous “over the line” clause, yet for the court of public opinion Schiller chose to cite other reasons, making it sound as though Rogue Amoeba violated an actual rule. The “without using approved APIs” seems meant to imply that there were APIs that Rogue Amoeba should have used, or that they used private APIs, when in fact neither is the case. It’s not clear to me why Apple decided to draw the line with this feature, when the now re-approved Airfoil Speakers Touch and some other approved apps also communicate via reverse-engineered AirPlay protocols.
Schiller also says:
Apple never said that we would pull the rug out from anyone, we in fact worked with this developer to ensure they update their app and remain on the App Store.
Recall that Apple’s first step was to pull the app, and it wasn’t until much later that it communicated with the developer at all. Schiller alleges that Rogue Amoeba violated an agreement, but Kafasis implies that Apple never specified what said violation was.
You’ve likely seen the Apple ad featuring Samuel L. Jackson using Siri. If you’ve used Siri yourself, however, you know the disclaimer of “Sequences shortened” is more than an understatement. They’ve edited out the inevitable “No.…NO.…NO!” as well as significant quantities of exasperated sighs. After hearing Jackson say the word “hotspacho” for the umpteenth time, I decided to run a little test.
I’ve stopped even trying to use Siri because the server is so rarely available.
Unlike with the App Store on your iOS device or in iTunes you won’t find a Gift This App link on the Mac App Store.
I haven’t heard any good reasons for this; Apple just doesn’t think it’s very important.
Jensen Harris (via Brooke Crothers):
Even with multitasking in the existing desktop still present (and improved), we did feel like only offering “one-at-a-time” in the Metro style experience was a bit of a constraint, and not totally true to the Windows history of multitasking. So we evolved Snap for Windows 8.This feature lets you run any two WinRT-based apps side-by-side, so that you can watch a video while you browse the web, or video chat while checking mail. And we created facilities for background processing of a wide class of apps, and background notification capabilities that are unique to Windows as well.
I like how open Microsoft is about their thought processes. It’ll be interesting to see whether they can pull off this “no compromises” thing.
Coda 2 represents a incredible overhaul of every facet of our venerable all-in-one web code editor. It’s a release packed with tons of improvements that will make you more efficient and faster at your job. And on top of that, it’s got brand new features that will make it an even more indispensable part of your process.
Looks very impressive. They also have an interesting pricing structure: $10 for the iPad app and $100 for the Mac app. The Mac app is discounted to $49 the first day, then $75 for an unspecified upgrade-pricing-for-everyone window. If you purchased Coda 1 (not from the Mac App Store) after April 10, you get a free update (at your leisure). It’s hinted that the price of the iPad app will go up, and it doesn’t scale down to work on iPhones. This is all pre-announced three days before anything goes on sale. I’m not sure whether this is a marketing tactic or a new attempt at Wil Shipley’s Gordian Knot of how (post–Mac App Store) to offer existing customers upgrading pricing without losing too many full-price sales to new customers.
Update (2012-05-24): Panic:
At the moment, there is only one difference between the two versions: the Mac App Store version will support iCloud syncing of Sites and Clips, and the direct version will not. This is a restriction imposed by Apple.
Apple often changes the conditions for Mac App Store eligibility, and it's possible we may have to modify or remove features from the Mac App Store version in the future. It's our intent to keep them as close to identical as Apple will let us.
Take the custom text selection method Panic built. It’s not entirely custom — it’s still fundamentally based on “drag handles” and a “zoomed-in view” of the cursor — but Panic reworked it to allow for faster selection by swiping on the left (where numbered lines are) and to visualize a larger, rounded “zoom selector” (they call it the Super Loupe) when you’re moving the cursor between characters. It feels much better than standard iOS text selection — faster, and somewhat more accurate — albeit it really needs to be experienced “in motion”, rather than through the screenshot I have embedded below.
John Carmack (via John Siracusa):
To measure display latency, I have a small program that sits in a spin loop polling a game controller, doing a clear to a different color and swapping buffers whenever a button is pressed. I video record showing both the game controller and the screen with a 240 fps camera, then count the number of frames between the button being pressed and the screen starting to show a change.
I think the lesson here is that intuition about performance bottlenecks is often wrong.
Nat!:
There was absolutely no compelling reason for me to update, but I did it anyway. Since then I am plagued with video problems, like can be seen on the small picture to the right.
The seems to be the rare maintenance update that introduces problems. The -[NSWorkspace iconForFileType:] method now returns generic document icons for me in certain circumstances. Another NSWorkspace bug leaks memory. Daniel Jalkut is seeing a new UI glitch. I’m seeing PDFView drawing glitches, which for Gus Mueller are accompanied by crashes. The video-related kernel panics that I started seeing with 10.7.3 are still occurring. I’ve also heard of problems with security-scoped bookmarks—introduced in 10.7.3 and essential for sandboxing—no longer working properly. It’s unfortunate that, as we near Mountain Lion’s release, Lion itself is not yet solid for everyone.
Ken Shirriff (via Collin Allen):
Disassembling Apple’s diminutive inch-cube iPhone charger reveals a technologically advanced flyback switching power supply that goes beyond the typical charger. It simply takes AC input (anything between 100 and 240 volts) and produce 5 watts of smooth 5 volt power, but the circuit to do this is surprisingly complex and innovative.
Comcast is suspending enforcement of its hard 250GB cap nationwide as of Thursday, while it prepares two regional tests of new caps that come with ways to buy chunks of data if you go over them. Users who repeatedly crossed Comcast’s 250GB cap, instated in 2007, have been be cut off and banned from the network for a year.
Good news.
Erica Sadun (via Christopher Forsythe and Mark Munz):
TUAW has been told that Apple will be rejecting all apps with hotkey functionality starting June 1, regardless of whether the new features are hotkey related or not. Basically, if you’re developing one of those apps, an app that assumes you can still add hotkeys, don’t bother submitting it to the Mac App Store.
My understanding was that hotkeys (e.g. created by RegisterEventHotKey) were allowed but that simulating keypresses and the accessibility APIs were not. I’ve found no official statement to the contrary. Tons of applications use hotkeys, from iTunes controllers and Twitter clients to OmniFocus, EagleFiler, and Acorn.
It doesn’t make sense that Apple would want to ban this popular and (seemingly) safe feature. Thus, my first reaction was that this story is probably incorrect. However, it was written by Erica Sadun with feedback from Gwynne Raskind, two writers/developers with reputations for knowing what they’re talking about. So I’m afraid that I must take it seriously.
Incidentally, one of the problems with the Mac App Store and sandboxing is that we don’t know what’s intended to work. When building an application that is to be compatible with Mac OS X 10.6, you can set Xcode to warn you about using APIs that were not available in Snow Leopard. (Unfortunately, Apple has been scaling back this “SDK” functionality so that now it only works for targeting the previous OS release. Good luck maintaining 10.5 or 10.4 compatibility when using Xcode 4 on 10.7.)
In theory, there could be a similar feature for the compiler to warn about using APIs that are not allowed in the Mac App Store. The headers for a method could be annotated to say that it requires Mac OS X 10.6 or later, or 10.8 or later when sandboxed. However, Apple has not even marked in the documentation which APIs (are supposed to) work in the sandbox. My guess is that they may not know. Thus, the process has been backwards compared with previous major transitions. Instead of Apple saying which features it intends to support or drop, developers are told to run their apps and file bugs when things don’t work.
Update (2012-05-17): Lex Friedman:
Macworld can confirm that no such hotkey ban is coming to the Mac App Store. In fact, Apple offers developers several public APIs that make simple work of creating global keyboard shortcuts, and those APIs aren’t going away.
I stand behind this story due to the evidence we received, but unfortunately it is evidence we cannot share publicly. While many have claimed our story is untrue, I can tell you that due diligence was practiced and, based on the evidence we received, what was indicated by Apple stands as written. Several clarifications have been added to this story, but all I can tell people is that either Apple is unsure of what hotkey functionality is in this case, or something has changed very recently in such a way as to negate what was said previously by Apple.
Apple is not on the record yet, and Macworld wouldn’t identify its sources or say whether they were at Apple, so I still see this as inconclusive. I would also point out that the existence of a public API means nothing. There are plenty of public APIs that are forbidden from the Mac App Store by policy or that don’t work under sandboxing, either by design or due to bugs. (Currently, it looks to me like RegisterEventHotKey does work in the sandbox.)
More curious, Friedman tweets:
If I had @ericasadun’s source for her initial story, I would have written the same one.
Update (2012-05-18): It’s not yet been revealed how both TUAW and Macworld had reliable sources with conflicting information. My guess is that TUAW really did have a solid story and that Apple changed its policies yesterday. I predict that we’ll see a follow up from TUAW saying that its source’s app is no longer being rejected due to using hotkeys.
Here are the takeaway points for me:
Update (2012-05-21): I had asked Apple to clarify whether hotkeys would continue to be allowed and just got the response that I expected:
You should be testing and developing your apps in line with the Mac Developer Program License Agreement and the Mac App Store Review Guidelines and I am not able to provide you with any information pertaining to RegisterEventHotkey. You may wish to develop your app exactly as you would like it to function and submit it for review. If during the review process the app gets rejected, you will be able to review the reason for rejection by visiting the Resolution Center within iTunes Connect.
I’ve long used the Keyboard pane in System Preferences to assign shortcuts for the items in “From” pop-up menu in Mail’s “New Message” window. This lets me send the message from a different account just by pressing a key.
(Interestingly, this same technique works for the standard “Save as PDF…” menu item when printing, but not for user-supplied PDF services.)
Mac OS X 10.7 Lion introduced a bug whereby editing a keyboard shortcut for any application would render the Mail keyboard shortcuts inoperable. If you examine Mail’s preferences file, you can see that a non-printable character is inserted on either side of the menu item title. Preferences for other applications are unaffected; I think some part of the OS doesn’t like that the titles of these menu items contain angle brackets.
Before editing a shortcut in System Preferences, you can use this Terminal command to save your Mail keyboard shortcuts:
defaults read com.apple.mail NSUserKeyEquivalents
Copy everything in curly braces, which for me is:
{
"Add Sender to Address Book" = "@~^$y";
"Michael Tsai <dropdmg@c-command.com>" = "@^$d";
"Michael Tsai <eaglefiler@c-command.com>" = "@^$e";
"Michael Tsai <mjt@c-command.com>" = "@^$c";
"Michael Tsai <mjt@mjtsai.com>" = "@^$m";
"Michael Tsai <mtsai@atpm.com>" = "@^$a";
"Michael Tsai <spamsieve@c-command.com>" = "@^$s";
}
To restore the Mail keyboard shortcuts, type:
defaults write com.apple.mail NSUserKeyEquivalents '
Then paste, enter the closing ', and press Return.
Update (2012-07-31): This bug seems to be fixed in Mountain Lion.
The developers of Perian, the free and extremely popular video format extender for QuickTime, have announced that they are ceasing work on the project. In a statement on the project’s Web site, the developers have said that it’s time to move on, their goal of making video content playback easier on the Mac having been met.
There are plenty of standalone Mac video players. Perian is interesting because it enables any application that supports QuickTime or Quick Look to play additional formats. QuickTime once had built-in support for playing Flash videos. These days, Apple would rather promote its preferred video formats than ensure that applications on its platform can play files that users encounter in the wild. (Imagine if there were popular image formats that Safari and Preview couldn’t display.) I haven’t been following the QuickTime API very closely, but my impression is that ever since QuickTime X in Snow Leopard, the entire plug-in system has been deprecated, with no replacement.
I’ve spent the last 3-4 months integrating Core Data syncing over iCloud into Mental Case for Mac. It is not in the wild yet, but we have started beta testing with a limited audience.
To say it has been a challenge would be an understatement — it has probably been one of the hardest tasks I have ever undertaken for a Mac or iOS app.
Update (2012-05-17): Part 2:
In other words, where with MobileMe there was a single truth database in the cloud, there is now just a collection of transaction logs from different devices, and a number of clients doing their best to independently reconcile those logs. As long as the updates are reasonably distinct, it works well, but when changes overlap considerably, you can get quite tricky situations. A lot of the discussion in this series of posts revolves around working around the conflicts that can arise.
Update (2012-05-26): Part 3:
For a start, any objects inserted while iCloud is disabled, and other changes made to the data, will not appear on other devices, even after iCloud is re-engaged. That means the user will see two distinct sets of data. They will wonder why the objects they see on one device are not appearing on the other. But that will likely be the least of the problems…
Update (2012-05-29): Part 4:
Having covered Core Data syncing via iCloud from a high level, in this post I want to introduce a simple test app, which will be extended over the coming weeks. The app should eventually contain most of the code snippets you will need to get your own app up and running with iCloud.
Update (2012-06-08): Part 5:
One solution to these problems is to add a file or files to the iCloud container to track which devices have contributed to the transaction logs. When a device starts syncing, an entry is made in the container. When the device stops syncing, the device entry is left in place as a record that it contributed to the iCloud logs.
Update (2012-06-16): Part 6:
The import takes place in a private context using a private persistent store coordinator, but it still makes use of your managed object classes, and uses key-value coding (KVC) to access properties. That means that if you have any side effects in your custom accessor methods, you could end up undermining the import.
[…]
Your app’s source can influence the import process in another way too. The validation rules of your entity model are applied during the import, as are validation checks in your managed object classes. If any fail, the import fails, and will never recover, leaving the app’s data in an inconsistent state across devices.
The May issue of ATPM is out:
Scott Hanselman (via Paul Kafasis):
The world’s most advanced phones include an icon that looks like a phone handset that you haven’t touched in 20 years, unless you’ve used a pay phone recently.
Also:
At some time in the past the magnifying glass became the “search everywhere” icon, but for some reason binoculars are for searching within a document. This makes no sense as magnifying glasses are for searching things that are near and binoculars imply breadth of search and distance. These two commands should have had their icons reversed!
Adobe has the expected list of caveats:
- Updates will take place through the Mac App Store, not via Adobe.com for this version of Lightroom. When we update Lightroom for new camera support (about 4 times per year), the Mac App Store version may be released at a different time than the update on Adobe.com
- There is no upgrade pricing available on the Mac App Store for Lightroom customers who own Lightroom 1, 2 or 3.
- Because there is no upgrade pricing or upgrade validation currently available on the Mac App Store, there is no guarantee that upgrade pricing will be available to Mac App Store Lightroom 4 customers when Lightroom 5 and future versions of Lightroom are released.
I’m more interested in what will happen to Lightroom 4 purchases when version 5 becomes available. If there’s still no upgrade functionality, Adobe will have to remove version 4 from the store when it adds version 5. My understanding is that apps that are removed cannot be redownloaded. You can make your own backup, but the Mac App Store receipt will be tied to your Mac’s unique ID. So it seems as though if Lightroom 5 comes out and you get a new Mac, you will not be able to continue using Lightroom 4 at all. To be clear, this situation is not unique to Adobe. It is just one of the higher profile companies that is working around Apple’s lack of support for multiple versions of a product.
Secondly, this is bad for scripting and for other applications that integrate with the product. A new product in the Mac App Store must have a new bundle identifier. So any code that was using the old bundle identifier to, well, identify the application will break.
I’d long pigeonholed Moom as a utility for moving and zooming windows, for people who didn’t want to do so by clicking and dragging. It sounded cool enough, but not particularly useful for me. I tend to keep my windows in fixed locations and don’t need or want to reshape them into different grids.
Then I happened to see a full-page ad in the paper edition of Macworld highlighting the “Save Window Layout Snapshot” feature, which I didn’t know about. I’d tried a couple utilities to do this years ago, but was never that happy with them. And during the Mini DisplayPort adapter fiasco I’d written an AppleScript to restore my hard-coded window positions. However, Moom is easier and better, so I’ve switched. Whenever my windows get messed up—from resetting the display adapter, a kernel panic, or switching from one display to two (or vice-versa)—it quickly fixes the positions of all my windows.
If
g_nameis non-nil, it’s a true value, so this function will be returning a true value. It might not beYES, but truth is truth in C, isn’t it? If this function returnedbool, it would return the correct value.Unfortunately, with
BOOL, it doesn’t. If the address happens to have a zero lower byte, this function will return zero due to the same slicing behavior.
I did some preliminary testing with version 1.0.2960.1377 of Google Drive. At first glance, it seems to be a lot like Dropbox except that it’s slow and doesn’t work very well. At launch, it fills the Console with errors like:
5/7/12 2:22:58.497 PM [0x0-0x70070].com.google.GoogleDrive: objc[1082]: Object 0x2f1a8d0 of class OC_PythonString autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug 5/7/12 2:22:58.497 PM [0x0-0x70070].com.google.GoogleDrive: objc[1082]: Object 0x2f10af0 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug 5/7/12 2:22:58.497 PM [0x0-0x70070].com.google.GoogleDrive: objc[1082]: Object 0x2f0f5f0 of class __NSCFData autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
This makes it appear as if the developers weren’t very experienced with Objective-C and also didn’t test it.
Uploading took around 20 minutes for a folder with under 100 files and 100K. (I never thought I’d write the phrase “slower than iDisk.”) It reported numerous “unknown” upload errors. They kept occurring when I clicked “Retry” but did not recur after restarting the Mac.
I waited 40 minutes for it to download 17 files totaling 60 KB, after which it seemed to have stopped making progress, and I gave up. Of the files that it completely downloaded, it did not transfer the following metadata: label, creation date, extended attributes, locked flag, invisible flag. Dropbox initially had problems with these as well, but as of version 1.0 it handles them properly. (The test file with the resource fork was one of the ones that didn’t download before I gave up.)
I assume that my experience is not typical, or I would have read about more people reporting problems. But from what I’ve seen, this is one Google product that should have stayed in beta.
Ed Bott (via John Gruber):
Microsoft’s decision to remove support for playing DVD movies in Windows 8 has caused some confusion. If the VLC media player can provide DVD support for free, why can’t Microsoft? For starters, Microsoft isn’t French.
Emil Protalinski (via Slashdot):
An Apple programmer, apparently by accident, left a debug flag in the most recent version of the Mac OS X operating system. In specific configurations, applying OS X Lion update 10.7.3 turns on a system-wide debug log file that contains the login passwords of every user who has logged in since the update was applied. The passwords are stored in clear text.
Anyone who used FileVault encryption on their Mac prior to Lion, upgraded to Lion, but kept the folders encrypted using the legacy version of FileVault is vulnerable. FileVault 2 (whole disk encryption) is unaffected.
User tarwinator posted about this in Apple’s support forum three months ago but didn’t get a response.
Update (2012-05-09): It’s fixed in Mac OS X 10.7.4.
Update (2012-05-10): Apple has posted a support article about the problem.
I am a self-funded Indie (lone) developer. I made a number of classic business blunders on the FaceSpan 5 project. I broke the golden rule: never (never!) rewrite a software product. I massively underestimated the effort required to complete the product. I set off without having sufficient resources to complete the project. Because I took so long to complete my work, the market moved on — AppleScript’s importance to the customers I intended to target declined. Some may argue that the market was never really there to provide a return for a product of this complexity. Finally, I didn’t pull the plug soon enough.
I never got into FaceSpan, but I’m a big fan of Alldritt’s main product, Script Debugger.
Josh Abernathy (via Jesper):
ReactiveCocoa gives us a lot of cool stuff:
- The ability to compose operations on future data.
- An approach to minimize state and mutability.
- A declarative way to define behaviors and the relationships between properties.
- A unified, high-level interface for asynchronous operations.
- A lovely API on top of KVO.
Those all might seem a little random until you realize that RAC is all about handling these cases where we’re waiting for some new value and then reacting.
Lots of fun with blocks, based on .NET’s Reactive Extensions (Rx).
Sam Livingston-Gray (via Jonathan Rentzsch):
Once people achieve some level of Git enlightenment, they tend to make statements of the form ‘Git gets a lot easier once you realize X’—but that doesn’t do much for people staring up Git’s steep learning curve.
My goal with this site is to help you, Dear Reader, understand what those smug bastards are talking about.
Not that Git is easy to use, exactly, but I think it’s somewhat unfairly singled out for criticism. The repository model is very logical.
When I first started using iOS’s on-screen keyboard, it was a revelation just how much I missed the arrow keys and modifiers (for moving by word or by line and changing the selection). Apple eventually added support for text selection and cut/copy/paste, with an interface that’s intuitive but very slow. Text entry and editing remain so unpleasant that I do them as little as possible, waiting until I’m back at the Mac and its real keyboard. Daniel Hooper created a demo showing how the iPad’s keyboard could be improved (via John Siracusa). His idea is to use the keyboard as a gesture area, swiping left and right to move the cursor or change the selection. This looks like a promising approach.
I’ve encountered a raft of kernel panics recently (eight in the past two weeks). The backtrace is always related to com.apple.NVDAResman, which seems to be the driver for my MacBook Pro’s NVIDIA GeForce graphics card. Strangely, this has only happened with Mac OS X 10.7.3, but the panics did not begin until two months after updating to 10.7.3. Perhaps there was another update to those drivers that I don’t remember.
Aside from being annoying, the kernel panics indirectly caused a more serious problem: I repeatedly left the house with stale OmniFocus data synced to my iPhone. I’ve used OmniFocus for years, and nothing like this had ever happened, so I had gotten to the point where I didn’t think much about syncing, assuming it would just work. Furthermore, when I tried to manually initiate a sync from the iPhone, the progress indicator would just spin and spin.
I looked in the Console log and found many entries like this:
4/26/12 5:12:03.161 PM Firewall: Deny connecting from fe80:5::62c5:47ff:fe37:29aa:58959 to port 49212 proto=6 4/26/12 5:12:06.868 PM Firewall: Deny connecting from 192.168.1.105:58960 to port 49212 proto=6
The iPhone had found my Mac, but the firewall was preventing it from connecting.
I don’t understand why this happens, because I verified in the “Security & Privacy” preferences pane that httpd (the Apache Web server, which OmniFocus uses when set to sync via Bonjour) was set to “Allow incoming connections.” The problem only occurs when Lion’s auto-restore feature has automatically relaunched OmniFocus (e.g. after a kernel panic). In that situation, the firewall will continue to block connections for days.
I’m not sure whether this is due to a bug in the OS or whether OmniFocus should be doing something differently on auto-restore. However, there is a workaround: if I manually quit and relaunch OmniFocus on the Mac, the firewall suddenly opens up and allows the iPhone to connect.
The other thing I’ve learned from these panics is that two of my favorite applications, NetNewsWire and Hibari, save certain state only when they quit cleanly. After the panic, old news items appear as unread, and the Twitter timeline is scrolled to the wrong place.
Goran Daemon P (via Justin Williams):
Reason for rejection is the fact that if the user does not have Dropbox application installed then the linking authorization is done through Safari (as per latest SDK).
Once the user is in Safari it is possible for the user to click “Desktop version” and navigate to a place on Dropbox site where it is possible to purchase additional space.
Apple views this as “sending user to an additional purchase” which is against rules.
I’m surprised it took this long for Apple to enforce its own insane rule.
Update (2012-05-02): Bryan Bishop:
Dropbox initially tried removing a link to the desktop version of the site as a possible workaround, but the review team continued to reject apps. Earlier this evening, the company posted a version of its SDK that removed the ability to create a new account altogether. While Dropbox believes this should resolve the issue, it’s hardly a convenient solution for iOS users looking to add functionality, and should only further stoke the flames of controversy over some of Apple’s review guidelines.
Update (2012-05-13): Dropbox complied with Apple’s guidelines by removing the option to create an account.
