If you add any external libraries, don’t modify them.

That said, if you need to change them to fit our app:

• Make it generic enough to be accepted by the original developer, if it fixes a general problem
• Try creating a subclass, or find other workaround, if it’s too specific to our app
• If you absolutely must modify the library, at least commit a clean copy of it to svn, then apply your changes and commit. This way we can have a diff of what we’ve modified and update the library easily in the future

This came from trying to update the XMLRPC library. Our version was really old, the first version committed to our svn already had modifications, in all this time they moved from svn to git losing the history. There was no sane way to figure out what our changes were compared to the original version to port them over the latest version, so I had to take a guess (only picked the changes after it was added to svn)

@WordPressiOS I'm requesting a feature: The ability to search or better options to go through history of blog posts. I got 1000+ posts.—
  (@XVerse10) December 16, 2011

@WordPressiOS I got 1000+ post it takes me forever to get to a post to edit from earlier this year.—
  (@XVerse10) December 16, 2011

@WordPressiOS When you do get to it. It doesn't save your position meaning to get back to it I have to start scrolling all over again.—
  (@XVerse10) December 16, 2011

First we’d need support on the XML-RPC api. In theory, metaWeblog.getRecentPosts supports everything that WP_Query supports, but I can’t find search on the documentation.

But even then, how do we decide what to keep? Most of the users will only care about the latest posts if anything, and keeping 1K posts in the app would add disk space, and possibly slow down the app.

Copy/Paste issues fixed! Please update to 2.9.3 and let us know how it works. cot.ag/sz28T2—
WordPress for iOS (@WordPressiOS) December 12, 2011

2.9.2 is out: Stability improvements and an "Update Available" notification. cot.ag/9Ft5OW—
WordPress for iOS (@WordPressiOS) December 05, 2011

‘NSInvalidArgumentException’, reason: ‘Cannot set metadata in read-only store.’

Looking at this thread and the dev forums, it seems like an Apple bug, but one user said:

My beta testers reported that syncing with iTunes seems to clear this error up- so my guess is that iTunes sync is fixing a permissions problem.

Let’s hope they’ll fix that in a next release, since it’s about 20% of the crashes for 2.9.1 right now

I’ll start working on the roadmap next week, and everything should have it’s own ticket so we can easily keep track of the changes and progress.

• Fixed freeze when picking photo from library [2239]
• Fixed crashes on iOS 4.0 [8.58% of crashes] [2236]
• Maybe fixed crash when memory warning issued while adding/selecting categories [4% of crashes] [2240]
• Try to avoid crash on weird cases when picking a photo [2.47% of crashes]. Can’t reproduce, but I’ve tried to make it not crash on unexpected values [2241]

Unsolved crashes:

• There’s a Safari bug on iOS 4.0 which makes WebCore crash [5.29% of crashes]. New version of the reader in 2.9.1 will at least not make it happen when users are somewhere else in the app, but will still crash when loading the articles that trigger that bug. That would also help pinpoint what the bug actually is
• The crash on ojbc_msgSend [4.47% of crashes]. We’ve had this one for a long time, and happens in very random places. At least users are now giving more details of what they were doing when app crashed. Cleanup and NSOperation in 3.0 will probably help getting rid of this one
• NSObjectInaccessibleException [3.17% of crashes]. In some edge cases, the app tries to show a comment which has been deleted (or marked as spam). It looks like it happens when the app was in the background and just launched opening a comment.
• The “Deallocation Problem” (more info) [2.59% of crashes]. Nasty bug which happens when a UIViewController does something on the background and gets released before the background thread is finished. That causes dealloc to be called from a background thread which is fatal when you have a UIWebView. Let’s move to NSOperation and stay away from performSelector* on 3.0

If you’re unsure in the future check the documentations, or run this:

ack -h -a '_AVAILABLE_STARTING\(.*, ?__IPHONE_4_[123]' /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk/System/Library/Frameworks

After looking at those results, I haven’t found anything else we use unsupported in 4.0