Auto Layout Shorthand is a poor man’s DSL wedged into a normal Objective-C dictionary literal.
Each key-value pair contains enough information to create one NSLayoutConstraint. This stands in contrast to [the Visual Format Language], where one string can be used to generate multiple constraints.
I like how you don’t have to put your variable names into a string or use NSDictionaryOfVariableBindings().
BitTorrent Sync is a Dropbox-like app that syncs a folder between distributed peers, rather than using a central cloud server. It supports shared folders with read-only as well as read-write permissions.
Update (2013-05-02): Unfortunately, it doesn’t sync extended attributes (xattrs) or Mac metadata.
Brian Greenstone’s book is now available as a free PDF download (via Peter Hosey). I remember enjoying it when it came out around the Panther timeframe. There’s probably still some relevant information in it, amidst reference to CHUD, Shark, Sherlock, and the old QuickTime APIs.
For views where the amount of time it takes to create them is crucial (like the contents of table view & collection view cells, paging views, etc.) you have to keep the view hierarchy very simple and closely watch the performance impact of Auto Layout. In these cases it might be worthwhile to try disabling Auto Layout before you go straight to drawing everything manually with Core Graphics.
RFC 6920 (via Manuel Simoni):
This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.
So, the next time you’re seeing general slowness on your Mac, don’t forget to give Launch Services a kick in the pants. Guaranteed to be more effective than zapping your PRAM.
The current command is:
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -seed -r
If you don’t remember the latest path to lsregister, Rich Siegel recommends using locate (although that requires that the locate.database be in order).
Perhaps more damningly, it’s particularly difficult to compose NSFastEnumeration, e.g. to produce objects based on the enumeration of some other object, as with a map, or worse, a convolution function (e.g. zip, zipWith).
This led me to decide that NSFastEnumeration is not the correct interface for these tasks […] Therefore I set about designing a better interface for lazy evaluation […]
This is really exciting work.
We are now six years into the iPhone 5 product cycle and quickly approaching a seventh iteration, yet Apple keeps repeating the same mistake when it comes to the Home button. It’s too early to tell if a metal shield and a bit of yellow tape will solve past woes caused by the Home button when it comes to the iPhone 5, but my gut tells me that the answer will be no. In the mean time, iPhone 4S Home button issues are starting to rear their ugly heads.
There is also a very clean flow of data from the worker contexts through the main context to the master context, which finally persists all changes. Since in this setup you never touch the master context, i.e. you never directly make changes to it, all changes flow through the main context. Therefore you will always have the latest data available on the main thread. No need for listening to change notifications and merging changes manually.
The key insight here is that managed object contexts in the same hierarchy can have different concurrency types. However it seems to me that this could potentially push a lot of work onto the main thread as fetches from that context would have to reconcile the differences between the disk and memory.
Update (2013-04-29): Florian Kugler:
Core Data stack #3 with its independent managed object contexts blew the other two options out of the water. It literally crushed them. I didn’t expect the nested setup #2 to be so much inferior.
Update (2013-05-13): Florian Kugler:
In this article I will take a look behind the scenes of how nested managed object contexts operate and explain why the performance of saving a child context often is much worse than manually merging changes into a context. Understanding how each approach works will make clear, that nested contexts are certainly not a replacement for “manual” merging.
Watts Martin (via John Gruber):
If there’s something I could do with OS X 10.6 that I can’t do with OS X 10.8, I haven’t found it yet. My software all still works.
I wish someone would make a list, because it surely wouldn’t be empty. Spaces has been reduced from two dimensions to one. Xcode and other apps have become less AppleScriptable. Safari has become buggy. Changes to Sync Services, without adequate replacements, broke Outlook and Yojimbo. Some things have improved, for sure, but there is also a lot that has become more limited, closed, or broken.
Again, no real evidence supports this—the iOS elements that have been migrated to OS X have not resulted in OS X becoming more locked down. And there’s no reason to think that more OS X technologies won’t move to iOS, making it less locked down.
He’s apparently never heard of sandboxing. Some apps bought from the Mac App Store on 10.6 have either had features removed or can no longer be updated. It also affects apps outside the Mac App Store. For example, Mail on 10.8 is sandboxed, which affects what plug-ins can do. Locking down Safari also affected plug-ins such as 1Password. Will Aperture plug-ins be next? Spotlight is also more locked down, which broke a feature of one of my apps. Restrictions on NSDistributedNotificationCenter affect the kinds of services that apps can provide.
While iOS is locked down by comparison—and there are some things that definitely do need to be opened up with respect to inter-application communication—an iOS device is an application console. We don’t complain (much) about a PlayStation 3 being “locked down” because it’s a game console. That’s what they do.
This is circular reasoning, with an appeal to a nebulous term that Apple has never used. The bottom line is that some people have needs that the product isn’t meeting. They can either go without (and try to influence future versions of the product) or switch to a different product (which has other drawbacks). Appeals to terminology attempt to shut down discussion without addressing the underlying issues in a constructive way.
It’s like saying in the early 80s: you don’t understand, it’s a Mac. It’s not supposed to have color, internal storage, networking, multiple processes, arrow keys, a compiler, a command line, etc.
Dave Winer’s new product, Fargo, is a Web-based outliner that edits OTML files in Dropbox.
Kiran Prasad (via Aaron Hillegass):
We have definitely shifted from HTML5 to native. The primary reason for that is, we’re seeing that more and more people are spending more time in the app, and the app is running out of memory. It’s not performance issues, like speed or rendering, but it’s still a big problem.
The second reason we’ve gone native is trying to get some of the animations — the spinners and the way they work — getting that smoothness, we felt like we needed native to really do that well.
WebCode is a “vector drawing app that instantly generates JavaScript+Canvas, CSS+HTML or SVG code” (via Matt Gemmell). The dynamic colors features looks interesting. PaintCode and Opacity are similar apps that generate Objective-C.
Florian Kugler (via Romain Briche):
After working on a fairly complex iPad app for the last six months together with Chris Eidhof, my personal bottom line for Interface Builder doesn’t look too positive with regard to these tasks. In fact, I’m willing to try out abandoning Interface Builder alltogether for the next project. This may sound pretty radical, but let me walk you through my thought process.
Tom Harrington introduces momdec:
a command-line tool for Mac OS X that takes a compiled Core Data model and decompiles it to produce an equivalent
xcdatamodelorxcdatamodeldsuitable for use in Xcode. The resulting model file can also be used with mogenerator to produce source code files for Core Data entities which have custom subclasses.
Sounds good, although in my view this functionality should have been built into Xcode.
Thinking about the other direction, it’s unfortunate that Core Data is so reliant on compiled model files that can only (officially) be generated from its undocumented model editor format. Right now there are APIs to construct models in code, but in various places you can’t actually tell the framework to use said models.
Ivan Drucker (via Clark Goble):
But if you really want synchronized Drafts, and you want the folder to behave correctly, you can go to your Gmail settings and under “Forwarding and POP/IMAP”, turn Auto-Expunge Off, and in the following section choose “Immediately Delete The Message Forever”. If you choose this setting, you must turn off Archive Messages on any iOS devices (see my previous post on this) or you will lose a message forever when you tap the Archive icon.
I don’t know when Google Maps acquired the capability to display a KML/KMZ file. But it can now do so, and that’s why the earlier link in this article works. You, too, can export a waypoint or a track from your GPS tracking device, hand it to Google Maps, and provide your friends (or the whole world) with a link they can click to see that information in Google Maps.
This is great—previously I had been firing up Aperture to view tracks. Google Maps also works with GPX files, but the GPX format is verbose so sometimes it gives me an error about the file being too large. My GPS logger uses the NMEA log format, but I was able to use GPS Visualizer to convert to the compact KMZ format.
When you push something to the limit all these technologies fail in their own special way. Started dropping technologies and asked themselves what they really wanted to be. Did a massive rearchitecture of everything. […] Now on sharded MySQL, Redis, Memcache, and Solr. That’s it. The advantage is it’s really simple and mature technologies.
This crash was happening regularly, sometimes as often as every 10 minutes. The Apple Store first recommended we wipe the device of all data and NOT restore from a backup. Problem still happened. Then the Apple Store replaced the device, and again we did not restore from a backup, and again, the crashes quickly resumed.
No restore from backup. Brand new hardware. Same crash. Diagnosing this just got interesting.
It turns out that Apple’s TextInput service uses Core Data and iCloud to store user dictionary entries such as shortcuts/abbreviations. His database became corrupt, which caused SpringBoard to crash. iOS doesn’t have any way to clean out this data, but he was about to do so from a Mac by digging into the Mobile Documents folder.
Dr. Drang notes some nifty features that Drafts has for appending or prepending to text files stored on Dropbox. It’s not really a Dropbox text editor, though. The main syncing is based on Simperium, the engine behind Simplenote, which was unreliable when I used it a few years ago.
Troy Koelling (via John Siracusa):
No, this must have been a mistake. Quartz Composer is not deprecated, and still fully supported in Mountain Lion. The bug reporting system, as you all are aware is like a game of telephone and although I do not know how this could have happened, I apologize for any confusion it has caused.
I was pretty sure I had seen an official notice that Quartz Composer had been deprecated. Glad to hear that’s not the case.
Apple has yet to bring full text searching to Core Data, or even Search Kit to iOS.
I wrote a simple sample app in order to see what kind of performance gain I might see from using a separate full text index in SQLite. The app loads 1682 text files from textfiles.com (where else?), that’s about 42mb of plain text, into both Core Data model objects and an SQLite database. I then timed how long it took to find a single word using both a full text query and a core data fetch request. For one query running on the main thread on slowest device I have (a 4th gen. iPod touch) the Core Data fetch took 9.34 seconds while the SQLite query only took 1.48 seconds.
It appears that the version of SQLite that ships with iOS 6 and OS X 10.8 actually have FTS enabled, are compiled to be threadsafe and have the more advanced searching enabled by default. Therefore it is not necessary to include your own custom build of SQLite in your application.
Cabel Sasser has a nice piece about no longer being fringe:
If Apple can find that comfortable middle, we’re set. With keynotes still watched closely, but constant flying-car expectations mellowed out. Innovating constantly, but at a possibly more relaxed pace, so that those innovations can truly stand out. Still pushing the industry, but still with something to prove.
“So that those innovations can truly stand out” is my new favorite euphemism.
If all else fails, Apple, take solace in this inarguable fact: We—the nerds—will always be there for you. As long as you don’t dump too much DRM in our dingles, or donate all your proceeds to dolphin-harvesting, we’ll buy every new thing, and hang on every word.
I was surprised that Sasser ended his article this way. If the Amiga and Mac users of yore were teenagers today, would they really choose iOS?
Does Apple—and the rest of the WebKit community—have the skill and capacity to continue to drive WebKit forward at a pace that matches Google’s grand plans for Blink? The easy answer is, “Of course it does! Apple created the WebKit project, and it got along fine before Google started contributing.” But I look at those graphs and wonder.
[…]
This all sounds great on paper, but in (several years of) practice, Google’s Chrome has proven to be far more stable and resilient in the face of misbehaving web pages than Apple’s WebKit2-based Safari. I run both browsers all day, and a week rarely goes by where I don’t find myself facing the dreaded “Webpages are not responding” dialog in Safari that invites me to reload every single open tab to resume normal operation.
Chris Adamson responds to Michael Jurewitz and Lex Friedman:
So what’s the proper response? Obviously: don’t write apps for sale in the App Store anymore. This has already happened. But it hasn’t manifested itself as a mass migration off the iOS platform (what, like Android users are any more willing to pay for apps?), but instead a migration into what one article (that I can’t find!) called the “middle class of developers making apps for corporate clients”.
[…]
True story: I was going over a GUI design for a client’s Mac app in a group chat and I said “man, I’d love a touch version of this on an iPad.” The client said they’d love to do it, but could never charge enough on the iPad to cover the development costs.
Think about that for a second. With 100 million iPads sold since 2010, versus a Mac installed base of about 60 million, the iPad market is nearly twice as large, yet cannot justify development or even porting.
As long as you have your client configured to cache a local copy of all messages and to delete messages on the server when you delete them locally, you maintain just as much control over your email as you do with POP. Most of the old assumptions that led users to favor POP — such as the expectation that a person will use a single computer for email most of the time, and the belief that online storage is expensive — are no longer valid in today’s world.
Paul Irish (via Jonathan Rentzsch):
If the browser is viewing that current page in through HTTPS, then it’ll request that asset with the HTTPS protocol, otherwise it’ll typically request it with HTTP. This prevents that awful “This Page Contains Both Secure and Non-Secure Items” error message in IE, keeping all your asset requests within the same protocol.
Panic’s StatusBoard iPad app looks interesting. But, frankly, I’m surprised they even submitted it to the App Store. I thought widget apps were banned.
The default Status Board comes pre-populated by several meticulously crafted widgets, including Clock, Weather, Calendar, Mail, Twitter, and RSS. To edit the Status Board you simply tap the gear button. Then you can drag in, drag out, re-size, re-arrange, and re-configure all the widgets until the layout best suits your needs. Different display modes, which vary from widget to widget, include things like lists, tickers, and graphs.
The first feature that I’m really excited about is HockeyApp integration. One of the widgets available in Status Board is a custom graph. HockeyApp has made it incredibly simple to pass URLs from Hockey to Status Board which will feed your widget the data necessary to chart a graph of your crash numbers. You can fit up to 6 different graphs comfortably in Status Board’s landscape orientation, and up to 8 in portrait. I’m hopeful that daily crash numbers are just the beginning. The HockeyApp API offers a lot of useful data, and the data you can graph in Status Board is really only limited by what people decide to make scripts for.
Panic provides instructions, accessible within the app, on how to provide the appropriate data sources. And a relatively new company called StatHat, which aims to make gathering data simple, is offering up Status Board-ready feeds, too.
In addition to the six Instant panels, which are very easy to set up, Status Board comes with its own “expert mode” for Pro panels. Using CSV, JSON, or HTML files hosted on a public server, users can create custom graphs, charts, and DIY panels using personalized icons, colors, data types, and more. As long as you can write a custom, valid JSON file and host it on a server (Dropbox is okay, too), you can feed it to Status Board and turn it into a custom module for the app. Panic provides extensive documentation for the Pro panels, so make sure to check out the PDFs linked inside the app to see the possibilities opened by support for CSV, JSON, and HTML.
Update (2013-04-14): Cabel Sasser:
It’s only been about a day since we unleashed our Status Board app to the world, and we’ve been truly astonished by the amount of cool things people have built to make it even more useful and amazing. Here are some of the greatest things we’ve seen so far.
Type2Phone is a nifty app that uses Bluetooth to let you type (or paste) text from your Mac to your iPhone (via Nicholas Riley).
Update (2013-04-15): More from Adam C. Engst.
Merkoski ran technology departments for a number of companies and headed e-commerce initiatives at Motorola before joining Amazon as a technology manager in 2005. For the next five years, he served at the company in a number of Kindle-related roles, helping to launch the first two Kindle models and the Kindle DX.
I think there’s an interesting story to be told about the development of the Kindle, but the review gives the impression that this is not the book to tell it.
Lockless (via John Regehr):
Reordering the three keywords
const typedef volatilewon’t change the meaning. Neither will moving any (or all) of those keywords before the “struct”. C syntax is very flexible.[…]
[In] C, the [] array access operation isn’t a sequence point. That means that even though you might expect to have some ordering between the calculation what array member to use, and the use of that array entry, there isn’t explicitly such a constraint in C99.
The main subject of this blog post is the “Re:” prefix used in the “Subject:” header line of most email replies, but the implicit subject is how MailMate handles the huge gap between theory and practice when dealing with many email headers. The story of the “Re:” prefix is in many ways a typical email header story. What may seem like a simple problem quickly becomes very complicated when 40 years of email history has made its mark.
EDW Lynch (via Scott Beale):
Inactive Account Manager is a newly announced feature for Google users that lets them decide what will happen to their Google data after they die or are incapacitated. Should a Google user’s account become inactive, the account can be set to delete itself after a set time frame of inactivity. Alternatively, the user can designate one or more trusted contacts to receive the user’s Google data […]
More companies should offer this.
Vicent Martí (via Jeff Johnson):
As we’ve seen, by overflowing the cookie jar in the web browser, we can craft requests with evil cookies that cannot be blocked server-side. There’s nothing particularly new here: Both Egor’s original proof of concept and the variations exposed here have been known for a while.
As it stands right now, hosting custom user content under a subdomain is simply a security suicide, particularly accentuated by Chrome’s current implementation choices. While Firefox handles more gracefully the distinction between Parent Domain and Subdomain cookies (sending them in more consistent ordering, and separating their storage to prevent overflows from a subdomain), Chrome performs no such distinction and treats session cookies set through JavaScript the same way as
Secure HttpOnlycookies set from the server, leading to a very enticing playground for tossing attacks.
Simon Dawlat (via Jeff Johnson):
Friday, April 5th was the day Apple decided to pull AppGratis out of the App Store, leaving our 12 million iOS users wondering where one of their favorite apps had gone, my 45 employees wondering if they’d still have a job next week, my partners and investors in shock, and myself with an absolutely crazy situation to deal with, thousands of miles away from our headquarters.
Despite Apple’s purchase of Chomp, searching the App Store seems worse than ever, so there’s clearly a role for apps like this. I’m no longer surprised when Apple pulls apps, even established ones. However, the process seems needlessly confusing and rude: last year an App Review team member had agreed that AppGratis was in compliance with the same rule it later told the Wall Street Journal that it violated.
This classic Bungie game is now available, free, for Mac OS X (via Peter Cohen).
When my iPhone 4S was about 18 months old, the power button stopped working. I first noticed this when it was vibrating in my pocket and I was unable to silence it. Then I found that the power button no longer moved at all. I was unable to turn off the display and sleep the phone. Judging from Google searches and the Apple support forums, this is a longstanding and common problem. Like the antenna problems, it began with the iPhone 4, which Apple is still shipping. It seems to be due to a design or manufacturing flaw, as it affects many users such as myself whose phones were never dropped or physically damaged.
There are workarounds for a stuck power button. You can go into Settings ‣ General ‣ Accessibility ‣ AssistiveTouch to enable a special on-screen button. It appears as a white circle, which you can drag around the screen when it gets in the way. Tap the assistive button, and you can access a software power button, which can both sleep and power off the phone. You can wake an iPhone using the Home button. To power it on, you must plug it into a Mac or battery pack.
I quickly found the software power button frustrating. I also worried whether continuing to use the phone in this state would make it worse. Would it become inoperable at an inconvenient time? I’ve read accounts of power buttons stuck in, such that the red slider to power off the iPhone keeps popping up. All you can do is tap Cancel and have it pop up again.
You can replace the power button yourself—in theory. The process looks far more involved than changing a Mac’s RAM or hard drive.
If your phone is less than a year old, it’s under warranty. Apple is well aware of this problem and can replace the power switch or give you a refurbished iPhone. (Be sure to make a full backup and unregister any authenticator apps before wiping the phone.)
If your phone is 1–2 years old and you paid $99 for AppleCare+, you can also get it fixed for free.
If you didn’t buy AppleCare+ or your phone is more than 2 years old, Apple will fix it for $199. This will also give you a new 90-day warranty. Your carrier upgrade eligibility will be unaffected.
What separates Fantastical from these others is that its window shows both the free-form entry field and the individual time/date/etc. fields, and as you type in the free-form field, animations show you how Fantastical is interpreting what you’re typing.
The Unofficial Fruit Company Open Source Git Mirror, or AOSM for short, is a collection of git repositories created from the Fruit Company Open Source web page, with tags for each project version and OS release. This makes it easy to, for example, compare xnu in 10.7.1 to xnu in 10.7.4 using regular git diffing tools, or see which OS releases contained zlib 37.2 (upstream zlib version 1.2.5) (project version numbers generally don't correspond to upstream project version numbers).
See also: Objective-C Runtime Releases and Apple-FOSS-Mirror.
When you work alone on a single project, it’s easy to unnoticeably break the build, or introduce some specific dependency on a quirk of your main work Mac. Since that’s annoying, I decided to set up Jenkins, a continuous integration system on my Mac mini that serves as my EyeTV DVR, media centre and home server.
When an application service is invoked, the application becomes active. There seems to be no way to avoid this. At best you can immediately hide the application, but there will still be a flicker as windows appear and disappear.
The second way: a .service bundle
If you want a service that is purely a background operation, you can create a standalone service that has no UI. It’s very simple once you know how, but I haven’t found a lot of help online, although some books discuss it and you can find examples on GitHub by searching for NSRegisterServicesProvider.
What bothers me today is the realization Apple might have handled the opening of the iPhone platform like a cargo cult […] By which I mean that Apple decided they needed to open the iPhone as a development platform, but I wonder to which extent they then did so by giving it the trappings of a platform more than the reality of a platform.
Civilized people don’t pay up. They band together, and fight, and eliminate the problem. The EFF is launching a major initiative to reform the patent system. At Stack Exchange, we’re trying to help with Ask Patents, which will hopefully block a few bad patents before they get issued.
Lodsys is back at it, and this time, again, it’s doing more than merely threatening. It’s actually filing lawsuits. These lawsuits against app developers are just part of a dangerous recent trend of patent trolls going after end-users. For example, a shadowy collection of shell companies has been blanketing the nation with letters demanding that companies pay them $1000 per employee for the privilege of using standard office technology like scanners and email. And another patent troll is targeting the podcasting community.
However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation - so today, we are introducing Blink, a new open source rendering engine based on WebKit.
By forking WebCore to create Blink, Google claims that all WebKit users will be able to innovate more quickly. Google can remove infrastructure that exists only to support WebKit2’s features, with the company claiming that in one fell swoop it can discard 7,000 files and 4.5 million of lines of code that exist only to support WebKit2’s architecture. In turn, this removes the ongoing cost of supporting this infrastructure.
Conversely, the WebKit project no longer needs to worry about making changes that might break WebCore for the way Chrome uses it.
Why couldn’t those cycle-time-improving changes happen inside WebKit? After all, much work has happened in the past 4 years (often by Googlers) to improve the directness of WebKit work: EWS bots, better code review flow, improved scripts and tools for managing checkins, the commit queue itself. The results have been impressive and have enabled huge growth and adoption by porters. WebKit now supports multiple multi-process architecture designs, something like a half-dozen network stack plug-ins, and similar diversity at every point where the engine calls back to outside systems for low-level implementation (GPU, network, storage, databases, fonts…you name it). The community is now committed to enabling porters, and due to WebKit’s low-ish level of abstraction each new port raises the tax paid by every other port.
The Chromium FAQ:
We want to do for networking, rendering and layout what V8 did for JavaScript. Remember JS engines before V8? We want the same sort of healthy innovation that benefits all users of the web, on all browsers.
[…]
We’ve seen how the proliferation of vendor prefixes have caused pain for developers and we don’t want to exacerbate this. As of today, Chrome is adopting a policy on vendor prefixes, one that is similar to Mozilla’s recently announced policy.
Update (2013-04-04): Maciej Stachowiak (via Daniel Jalkut):
Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no.
At that point, our choices were to do a hostile fork of Chromium into the WebKit tree, write our own process model, or live with being single-process forever.
Brendan Eich (via John Gruber):
Servo is an attempt to rebuild the Web browser from the ground up on modern hardware, rethinking old assumptions along the way. This means addressing the causes of security vulnerabilities while designing a platform that can fully utilize the performance of tomorrow’s massively parallel hardware to enable new and richer experiences on the Web. To those ends, Servo is written in Rust, a new, safe systems language developed by Mozilla along with a growing community of enthusiasts.
Daniel Terdiman (via John Gruber):
On April 10, 1978, the contract was signed. For $13,000 -- $5,200 up front, and $7,800 on delivery, and no additional royalties -- Shepardson Microsystems would build Apple’s first DOS -- and hand it over just 35 days later. […] For its money, Apple would get a file manager, an interface for integer BASIC and Applesoft BASIC, and utilities that would allow disk backup, disk recovery, and file copying.
Wikipedia has more information.
Rebecca Grant (via Brent Simmons):
People on online forums, publications, and blogs say their Google Alerts have dwindled to the point of uselessness. Trade publication The Financial Brand reported that its Google Alerts have slowed to a “trickle,” with the volume decreasing by at least 80% and dropping from 20-35 emails per day with 4-12 results down to 4-8 emails per day with 1-3 results each. Furthermore, “the results are crummier than ever.”
I’ve noticed this as well.
What I enjoy about April Fools is that it’s a chance to say and do things that are patently untrue, but that can be based on an entirely valid point of view or desirable outcome. It’s just a different method of conveying the same information. For instance, I’ve been planning to write a lengthy dissection of all that’s wrong with the Apple’s App Store policies, but I just couldn’t bring myself to the necessary pitch of negativity. It was far more fun to write the “App Store 2.0 Policies Address Developer Complaints” article, and I was able to make exactly the same points. And I really would like to see Apple do a lot of what Rich outlined in “iCloud for Families Debuts.”
For example, we found that automated cross-references often caused corruption in our Word (.doc) files, and we eventually banned their use in Take Control manuscripts. We also developed specific ways of working to reduce the impact of a corrupted document. Before opening a file, each of us would make a copy in a separate folder, and increment a version number in the filename, making it easy to revert to a previous version should corruption crop up.
[…]
Click at the very beginning of the corrupted document to set the insertion point there, scroll to the end of the document, hold down the Shift key, and click again just before the last paragraph mark in the document. (Various document attributes are stored in that last paragraph mark, so it’s a place where corruption can lurk.) Copy the selected text, switch to the new document, paste the text, and save with a new name.
Microsoft MVP John McGhie says you can avoid corruption by not using Word’s change tracking feature, direct formatting, or drag and drop:
Of course Microsoft Word is not perfect: it is built down to a price! FrameMaker is about 800 bucks a copy, and it crashes nearly as often as Word. InterLeaf is about $135,000 a copy, and it still crashes. I am sure that if all of the Word users in the world agreed to pay $250,000 a copy for Word, Microsoft would be delighted to fix all the bugs in it. But I am not willing to spend that amount of cash, so I put up with the bugs…
This makes me sad. Word has been corrupting my longer documents (15+ pages) since I began using it to write them in 1992 or so. Documents can become corrupted even if Word doesn’t crash. So I’ve avoided it where possible. Meanwhile, I’ve created thousands of pages of documents in FrameMaker and never once saw any corruption, despite all the crashes associated with running atop the classic Mac OS. Unfortunately, Adobe hasn’t done much with FrameMaker lately and never Carbonized the Mac version.
Like Dropbox, Google Drive, or Microsoft’s SkyDrive, the Cloud Drive desktop application (download it here) creates a new folder in your file manager. The desktop application supports all Windows versions from XP to 8 and Mac OS X 10.6, 10.7, and 10.8.
The application requires Java.
Pros: Cheaper than Dropbox for high capacities, no Finder haxie, doesn’t require admin privileges.
Cons: No file history, no API that I could find, more limited sharing features, no compelling advantages at the free tier.
Update (2013-04-02): I did some testing, and it appears to discard Finder labels and extended attributes.
In fact, if we take a look at the percentages, apps on the Top Grossing list are, on average, 294% more expensive than apps on the Top Paid list. Meanwhile, the median price of an app on the Top Grossing list (again, the middle of the dataset) is 329% more expensive than the Top Paid list.
If you create a single serving app that mostly solves an occasional need then sure, I’ll give you a cup of coffee’s worth of cash for it. But if you fundamentally change my life, how I work, or make it easier for me to get more done with less effort, I will pay you truckloads of cash. Most users are exactly the same. Solve a big need for them in a simple, delightful, and thoughtful way and theywill give you money. Cheap apps might get downloads, but higher priced apps pay the bills.
As a simple thought experiment, I want you to think about the price of your app right now. Just think about it. Now think about how many people bought your app last week. If you doubled the price of your app, and you end up losing less than 50% of your buyers, you just made money. Think about that for a moment. If the percentage change in your price is greater than the percentage change in units sold, you just made money.
As it turns out there are a lot of other fringe benefits from higher prices. Fewer customers means lower supports costs. Lower support costs means more revenue going toward development and future products.
If you want to make money and be a lasting part of this community, find hard problems to solveand solve them. Be a domain expert in something. Solving hard problems not only helps the people who have these hard problems, it also creates a barrier to entry for the next person.
And yet, despite their looks they were typically very featureful and commanded an average selling price of $54.79. This was reassuring insofar as it made it clear we had a more premium market, operating at a sustainable price, and likely in desire of a well organized, easy to use tool. So with that in mind we set out to try Kaleidoscope 2 at two different price points — an initial launch at $34.99 and an eventual full price of $69.99.
