1. Bundle ID is case-sensitive. If it is com.moke.app in the iTunes Connect but com.moke.App in App-Info.plist — that is default Bundle ID set in your app if you named your Xcode project “App” — IAP will not work.
2. “Waiting for Screenshot” is not a good status. At least you should upload a placeholder screenshot and let the product status be “Ready to Submit”.
3. No new Development Provisioning Profile is required. Though Technical Note TN2259 tells you to “Create, download, and install a new Development Provisioning Profile that uses your App ID enabled for In-App Purchase as seen in…”, it is not required if you are using a Development Provisioning Profile “Managed by Xcode” — it works for IAP apps even though it has a different App ID. Of course, it works for development installations only and you need setup Distribution Provisioning Profiles to distribute any apps no matter they have IAP or not.

One more thing. It’s not Apple’s One More Thing. In fact, it is one more thing that Apple does not like. If you are using a jailbroken device, make sure you uninstall AppSync from Cydia before testing IAP.

我早就向 iA Writer 的开发者反映过中文输入时的跳动问题。当时他们感谢了我反馈这个 bug，并声称尽力在后续版本中解决。

半年过去了，iA Writer 1.2.1 都出了，这个问题仍未解决。我再次去询问。这次他们说：“iA Writer 本来就没有声称支持中文输入。” Fuck！

App Store 退款

于是，我一怒之下首次在 App Store 申请退款，但是为时已晚：

Dear Ling,

When you first noticed that you could not use the application for the purpose you intended you should have contacted the iTunes Store for a refund.

Regrettably we cannot be held responsible for developers giving false information on updates that they plan on releasing in the future.

The iTunes Store will not be able to offer you a refund. Since the system does not allow refunds past the 60 day point we very strongly encourage customers to notify the iTunes Store of any issues you have with your purchases within that 60 days time frame.

In light of the current circumstances I do hope you have a pleasant day, Ling.

Sincerely,

Missy

iTunes Store/Mac App Store Customer Support Senior Advisor

简单复述：

1. 一旦发现 app 不好用，第一时间申请退款。
2. 相信开发者所谓的“以后会修正”是你的事，App Store 不对此负责。
3. 退款有时间限制，须在购买后 60 天之内提出。
4. 虽然你被坑、退款不成，我们还是希望你有开心的一天。

喜欢的话，可从 GitHub 上获取。

例如，在下图中，我在给 Apple 报 bug，要提交一个 Sample Code，位于 /Users/an0/dev/Projects/iOS/Bugs/CoreDataBug.zip。可见我要往下走三层目录，而且考虑到每一层目录下不光有我的目标路径，还有其他干扰项，这一路走到最后不容易。

我所知道的快速方法有两种，一种应该是资深用户所知道的，另一种是我自己刚发现的。

Finder 快捷键法

显然，文件选取窗长的很像 Finder 窗口，事实上也确实是。不显然的是，Finder 的快捷键在文件选取窗也是有效的。所以我们可以使用 Go 菜单下的这些快捷键来快速定位。其中最强大的是 Go to Folder…，但是需要你熟知目标路径，而且 Finder 的路径补全很慢。

直接拖拽法

这我是用 Lion 后无意间发现的，不确定 Lion 之前是否就支持了。

一般来说，我们要选取的目标文件是刚操作过的或常操作的文件，它们所在的目录已经在 Finder 中打开。比如，我这里要上传的 Sample Code 就是刚压缩好的，就在眼前。

很自然的，我就想把它直接拖拽到文件选取窗。令人惊喜的是，竟然真的可以！文件选取窗会自动跳转到目标目录并选中目标文件！太爽快了！

事实上，直接拖拽的源头不仅限于 Finder，其他支持拖拽的 app 也可作为文件来源。比如，我们可以直接从 iPhoto 中拖拽一张照片到文件选取窗。

The most used and simple one is duration:

duration
Specifies the basic duration of the animation, in seconds.

Nothing needs further explanation here.

The duration you specify may differ from the real duration you experience, depending on the parent time space or speed:

speed
Specifies how time is mapped to receiver’s time space from the parent time space.

So an animation with duration of 1 second and speed of 1 is the same as an animation with duration of 2 seconds and speed of 2, when mapped to real time space.

The two repeating properties — repeatCount and repeatDuration — are as clear as they are named. So is autoreverses.

Finally, we are talking about the three interesting but not intuitive properties:

beginTime

beginTime
Specifies the begin time of the receiver in relation to its parent object, if applicable.

If an animation is in an animation group, beginTime is the offset from the beginning of its parent object — the animation group. So if beginTime of the animation is 5, it begins 5 seconds after the animation group begins.

If an animation is added directly to a layer, beginTime is still the offset from the beginning of its parent object — the layer. But since the beginning of a layer is in the past¹, I can not simply set beginTime to 5 to delay the animation 5 seconds, because 5 seconds after the beginning of a layer is probably still a past time. What I usually really want is a delay relative to when the animation is added to the layer — denoted by addTime. So

animation.beginTime = addTime + delay;

In order to get addTime, I can use CACurrentMediaTime and convertTime:fromLayer::

addTime = [layer convertTime:CACurrentMediaTime() fromLayer:nil];

If beginTime of the layer itself is to be set, addTime must be calculated after it is set because beginTime shifts the time space of the layer.

These things can be chained up:

CFTimeInterval currentTime = CACurrentMediaTime();
CFTimeInterval currentTimeInSuperLayer = [superLayer convertTime:currentTime fromLayer:nil];
layer.beginTime = currentTimeInSuperLayer + 2;
CFTimeInterval currentTimeInLayer = [layer convertTime:currentTimeInSuperLayer fromLayer:superLayer];
CFTimeInterval addTime = currentTimeInLayer;
CAAnimationGroup *group = [CAAnimationGroup animation];
group.beginTime = addTime + 1;
group.animations = [NSArray arrayWithObject:anim];
group.duration = 2;
anim.beginTime = 0.5;
[layer addAnimation:group forKey:nil];

timeOffset

timeOffset
Specifies an additional time offset in active local time.

It’s not clear what it means from the words. But with a very simple example you’ll get it.

Supposing a 3-second animation with states s₀, s₁, s₂, s₃, wherein s_n denotes the state at second n. The normal state sequence without timeOffset is:
s₀ ➔ s₁ ➔ s₂ ➔ s₃

With timeOffset set to 1, the state sequence becomes:
s₁ ➔ s₂ ➔ s₃ ➔ s₀

With timeOffset set to 2:
s₂ ➔ s₃ ➔ s₀ ➔ s₁

Shift and wrap around. That’s it.

fillMode

fillMode is really badly documented. I can figure out kCAFillModeRemoved and kCAFillModeForwards but have no idea what kCAFillModeBackwards and kCAFillModeBoth are about.

Fortunately, they turn out very straightforward if you see them in practice.

Supposing an animation in an animation group configured as follow:

anim.beginTime = 1;
anim.duration = 3;
CAAnimationGroup *group = [CAAnimationGroup animation];
group.animations = [NSArray arrayWithObject:anim];
group.duration = 5;

Denote initial state of anim as s_i and final state as s_f. Hence in group’s time space:
s_i = s₁
s_f = s₄

Normally, there is no s₀ or s₅, because anim is not in effect during [0, 1) or (4, 5]. And it is what kCAFillModeRemoved means.

With kCAFillModeForwards, the state sequence of anim extends forward to the end of its parent time space, that is:
s₁ ➔ s₂ ➔ s₃ ➔ s₄ ➔ s₅

But what should s₅ be? I believe you can guess it.
s₅ = s_f = s₄

After anim is completed, it remains. It is what filling forward means. Quite intuitive, if put clearly, isn’t it?

kCAFillModeBackwards is the mirror of kCAFillModeForwards, which we can easily tell from their names. Actually, it is.

If fillMode of anim is set to kCAFillModeBackwards, the state sequence extends backward to the beginning of its parent time space, that is:
s₀ ➔ s₁ ➔ s₂ ➔ s₃ ➔ s₄
with
s₀ = s_i = s₁

Before anim begins, it appears. It is, indeed, filling backward.

At this time, kCAFillModeBoth is a nothing mysterious at all. It is just kCAFillModeForwards + kCAFillModeBackwards, filling both way:
s₀ ➔ s₁ ➔ s₂ ➔ s₃ ➔ s₄ ➔ s₅
with
s₀ = s_i = s₁
s₅ = s_f = s₄

To do you a further favor, I re-document fillMode below, in the way it should have been documented in the first place:

fillMode
Determines the receiver’s presentation during its inactive duration.

Discussion
The possible values are described in “Fill Modes”. The default is kCAFillModeRemoved.

Fill Modes
These constants determine how the timed object behaves in its inactive duration. They are used with the fillMode property.

NSString * const kCAFillModeRemoved;
NSString * const kCAFillModeForwards;
NSString * const kCAFillModeBackwards;
NSString * const kCAFillModeBoth;
NSString * const kCAFillModeFrozen;

Constants
kCAFillModeRemoved
The receiver does not appear until it begins and is removed from the presentation when it is completed.

kCAFillModeForwards
The receiver does not appear until it begins but remains visible in its final state when it is completed.

kCAFillModeBackwards
The receiver appears in its initial state before it begins but is removed from the presentation when it is completed.

kCAFillModeBoth
The receiver appears in its initial state before it begins and remains visible in its final state when it is completed.

That’s all. I think I’ve filled your mind quite full. You can get the sample code on github.

First of all, you should RTFM(Read The Fabulous Manual). Secondly, of course, you should watch the nice Session Video 424 of WWDC 2010 and play with the sample code Animation101.

Now, I assume you’ve done all the prerequisite work so you must be familiar with that bouncing ball which is our protagonist.

Bouncing is one of the simplest form of animation, just moving from a position to another position and back. But as you are going to see below, with some extra flexibility requirements, such a straight moving is not so straightforward in code.

Here is bouncing I want:

1. First tap triggers the fall of the ball.
2. Second tap triggers the rise of the ball.
3. Second tap can happen half-way along the fall and the bouncing should start immediately at that time and position.

Method 1 — Property animation

This is the most straightforward and recommended method. Nothing could go wrong.

if(viewState == 0) { // First tap.
        [CATransaction setAnimationDuration:2];
        ball.position = p2;
}  else { // Second tap.
        ball.position = p1;
}

Method 2 — Explicit animation with cancelation via delegate

Because the second animation may happen half-way during the first animation, I need to cancel the first one.

But when?

To ask this question, you should know how Core Animation interpolates values.

The relevant rule here is the fifth one:

toValue is non-nil. Interpolates between the current value of keyPath in the target layer’s presentation layer and toValue.

It is a good one for my purpose – bouncing from the current presentation position. If only I can keep the current presentation position value.

As soon as an property animation is canceled, the presentation value of the property is gone, and the model value is used instead. So if I cancel the first animation before the second one begins, the start position(the model value, which is never changed and always the initial position) and end position will be the same, hence no visible animation will happen.

Following preceding analysis, I should not cancel the first animation until the second one begins; and I must cancel it no later than the second one ends, otherwise the first one may continue after the second one ends — assuming the first one is longer than the second one.

Fortunately, CAAnimation has two delegate methods reporting animation progress:
–animationDidStart:
–animationDidStop:finished:

Taking them at face value, I think –animationDidStart: offers a perfect cancel point. However, it turns out that it is a bit too early¹, so I have to use –animationDidStop:finished:.

if(viewState == 0) { // First tap.
        CABasicAnimation *move = [CABasicAnimation animationWithKeyPath:@"position"];
        move.removedOnCompletion = NO;
        move.fillMode = kCAFillModeForwards;
        move.duration = 2;
        move.toValue = [NSValue valueWithCGPoint:p2];
        [ball addAnimation:move forKey:@"move"];
}  else { // Second tap.
        CABasicAnimation* stop = [CABasicAnimation animationWithKeyPath:@"position"];
        [stop setValue:@"stop" forKey:@"tag"];
        stop.delegate = self;
        stop.toValue = [NSValue valueWithCGPoint:p1];
        [ball addAnimation:stop forKey:@"stop"];
}

- (void)animationDidStop:(CAAnimation *)anim finished:(BOOL)flag {
        NSString *tag = [anim valueForKey:@"tag"];
        if ([tag isEqualToString:@"stop"]) {
                [ball removeAnimationForKey:@"move"];
        }
}

Method 3 — Explicit animation with overwriting

As you can see, canceling the first animation after the second one begins is tricky. And to be honest, I’m not sure what’s the behavior of two animations of the same property occurring simultaneous.

A better approach is to capture the current presentation value myself and use it as the fromValue, and to cancel the first animation before the second one begins. It is much cleaner logically and reliable behaviorally.

There is a nice feature I can use to cancel an animation with another by overwriting — simply assigning the same key as the first one to the second one when adding the second one to the layer.

if(viewState == 0) { // First tap.
        CABasicAnimation *move = [CABasicAnimation animationWithKeyPath:@"position"];
        move.removedOnCompletion = NO;
        move.fillMode = kCAFillModeForwards;
        move.duration = 2;
        move.toValue = [NSValue valueWithCGPoint:p2];
        [ball addAnimation:move forKey:@"position"];
}  else { // Second tap.
        CGPoint startPoint = ((CALayer *)ball.presentationLayer).position;
        CABasicAnimation* stop = [CABasicAnimation animationWithKeyPath:@"position"];
        stop.fromValue = [NSValue valueWithCGPoint:startPoint];
        stop.toValue = [NSValue valueWithCGPoint:p1];
        [ball addAnimation:stop forKey:@"position"];
}

Method 4 — Fall with property animation and rise with explicit animation

Though I don’t know why you would want to use this manner, I want to show you how to properly implement it.

The fall part is exactly the same as that of Method 1, while the rise part is almost the same as that of Method 3. Reasonable enough. However, there are two things you must pay attention to:

1. Property animations carry implicit keys named after their key paths. So the key “position” is used for the second animation to overwrite the first one which is a position property animation.
2. Even though I’m using explicit animation for the rise part, I still need to reset the model value because presentation changes do not update modal layers while modal changes do update presentation layers.

if(viewState == 0) { // First tap.
        [CATransaction setAnimationDuration:2];
        ball.position = p2;
}  else { // Second tap.
        CGPoint startPoint = ((CALayer *)ball.presentationLayer).position;
        ball.position = p1;
        CABasicAnimation* stop = [CABasicAnimation animationWithKeyPath:@"position"];
        stop.fromValue = [NSValue valueWithCGPoint:startPoint];
        stop.toValue = [NSValue valueWithCGPoint:p1];
        [ball addAnimation:stop forKey:@"position"];
}

Method 5 — Fall with explicit animation and rise with property animation

Just to be complete. Still two notice points:

1. The key “position” is used for the first animation so that the second one, which is a position property animation, can implicitly overwrite the first one.
2. I must set the model value of position away from the initial value², otherwise when I set the modal value back to the initial value Core Animation will not notice any change of the model value and will not trigger any animation.

if(viewState == 0) { // First tap.
        CGPoint startPoint = ball.position;
        ball.position = p2;
        CABasicAnimation *move = [CABasicAnimation animationWithKeyPath:@"position"];
        move.removedOnCompletion = NO;
        move.fillMode = kCAFillModeForwards;
        move.duration = 2;
        move.fromValue = [NSValue valueWithCGPoint:startPoint];
        move.toValue = [NSValue valueWithCGPoint:p2];
        [ball addAnimation:move forKey:@"position"];
}  else { // Second tap.
        ball.position = p1;
}

You can get the sample code on github.

The problem is that sometimes we are not sure whether there are Private API used in our code, especially with third-party frameworks involved.

Since Apple can automatically detect Private API usage, why not:

1. Run the auto detection as soon as apps are submitted, so that API-incompliant apps can be rejected immediately, rather than after a week of waiting.
2. Better yet, offer this auto detection tool to us developers, so that we can self-detect our apps before submission. It can save huge amount of time for both Apple and developers.

Another baffling problem is that any occurrence of selectors with the same name as any mysterious-unknown-to-developers Private API seems to cause apps to be identified as incompliant and rejected. This is the equivalence of forbidding people to call their innocent friends by their names, just because they bear the same names as some unknown bad guys. In this case, we even don’t know the existence of these bad guys; they are Private.

As a developer, I want things to become better for all of us. Please fix this, Apple.

If you are a developer who also want better Private API detecting tools and policy from Apple, please join me by duplicating my bug report #9016940. You can simply quote the content of this article above – it is Public.

However, I recently found some annoying problems of KVO while building some reusable programming components¹ for Voodo and future iOS projects.

Observers can not be queried

Observers are stored in dictionaries², so it should be very easy to query whether an object A is a registered observer of object B. But one can’t do that.

Unregistering an unregistered observer throws exception

One can not query whether A is an observer of B in the first place, and can neither try to unregister it from B when one wants to ensure that A is unregistered from B. It is just ridiculous! And why is removing a nonexistent observer so fatal while removing a nonexistent entry from a collection is reasonably ignored?³

Observers/observees don’t auto-dissolve the KVO relationship in dealloc

It can be easily done in KVO framework code since it already has the data structure keeping the observer-observee relationship information, and is very reasonable things to do – when any part of a relationship is gone the relationship is ended. Without the auto-unregistration, developers’ responsibility is unnecessarily heavier. In fact, it is no easy work in cases where observers outlive observees, because an observee needs to notify its observers of its death so the observers can detach themselves from the dying observee.⁴

All in all

KVO leaves some extra, tedious, and burdensome relationship management work to us while it could be easily and efficiently done at the root of itself.⁵

The KVO relationship management is especially stressful for observers watching many dynamic observees which is not unusual for generic components – UINavigationController and UITabBarController both manage a dynamic group of UIViewControllers and may observe some properties of them. It is even worse in my component because not only the observee but also the observed properties of them are dynamic. May Apple save me (and you?).

HeaderDoc is obviously not favored by developers. Doxygen is better and even officially advocated by Apple, but still tedious to use and just can’t generate Apple standard documentations(see a nice example here). Doxyclean is very helpful in converting Doxygen output to resemble Apple Developer Documentation, but seems not capable to generate Xcode Documentation Sets. Following the work of Doxyclean, appledoc supplements some missing features like Xcode Documentation Set generation.

To sum up, there are several third-party tools doing the work that should be better done by Apple in Apple way. Even though they can do their best to generate very Apple like documentations, they can not offer the smooth integration in Xcode that is otherwise possible if it is done by Apple.

So, I’ve posted a bug report(Problem ID: 8193210) to request such a Documentation Set generation tool. If you also want it, please go to duplicate a bug report with following content:

I vote for bug report ‘8193210′.

Summary:
Documentation set generation tool in Xcode to generate documentation set in the style of Apple Developer Documentation is necessary for a prosperous Apple developer community. The current HeaderDoc and doxygen are both far from the Apple standard.

Steps to Reproduce:

Expected Results:

Actual Results:

Regression:

Notes:

Read this article to learn why and how to vote for a bug report.¹

对 app 自身的截图，用真机 + Xcode 就能完美解决，但是对截图做注释就需额外的工具来完成。

一说到对图片进行操作，大家容易先想到 Photoshop, Illustrator，OmniGraffle 等重器，轻一点的也是 Acorn，Pixelmator 等。

这些专业的图片编辑软件确实强大，有些功能只有它们能提供。比如，我试了一圈，最终发现还是 Illustrator 里的 gradient 强大，是唯一一个直接支持 ellipse gradient 效果的，于是在对截图做聚光效果时都是用的 Illustrator。

既然我在对 Voodo 2 做截图时用的是 Xcode，后续工作是图片注释，为什么还需要截屏软件呢？

这是因为，其实大多截屏软件都自带注释功能，足以应付绝大多数需求；而且因为 Voodo 有同步 Google Calendar 的功能，我需要对 Google Calendar 上的操作进行一些截图。

下面就我用过的一些截屏软件做一个简单的比较（排名无明显先后）：

Snagit

Snagit 不愧是老牌领头羊，beta 就已经多方面超越其他先入场的小弟了，操作的灵活性，注释工具都是最好的。beta 版免费使用，很爽。

没有单独的 Full Screen Capture，那是因为根本不需要，人家的 All-in-One Capture 太帅了，自动识别 Full Screen，Window，甚至 Region in Window，还有 Capture Scrolling Area 能对需要滚动才能看全的页面做完整的截图。

Share 功能尚未成型，暂时只内嵌了 Email 功能。相信正式版肯定会有完善的 Share 功能，看看 TechSmith 的其他软件就知道了，何况人家还拥有自己的专业多媒体资源分享网站 Screencast.com。

Snapz Pro X

Snapz Pro X 没有注释功能，也不带 Share。但就截图的一个“截”字来说，Snapz Pro X 确实可算是最强悍的，算是名副其实。看一个它特有的截图功能：

其实把它放到这里并不完全合适，因为 Snapz Pro X 同时还是强大的 Screencast 录制软件。我购买它就是为了给 Voodo 录制 demo 及 promo video，配合着 iMovie 做的后期制作，一般的效果都能达到。

Skitch

Skitch 的 UI 设计相当独特，类似一个相框，上传分享特别方便（skitch.com，flickr，Mobile Me 等一应俱全），截图质量和注释工具都不错，而且免费。性价比最高，估计是目前最普及的截图软件。我一般都通过 Skitch 上传到 skitch.com 秀图给别人看。

LittleSnapper

LittleSnapper 可能是最眼熟的一个名字。软件本身 UI 也算清爽，功能也算齐全，支持多种 Share 方式，包括 flickr，但上手感觉不利索，不像名字取的那样 little。

我特别不喜欢它的截图方式，定位不如其他三个的十字交叉线来的方便：

不过，LittleSnapper 也有亮点：1) 组织管理功能比较强大，适合剪贴报爱好者；2）强大的网页截图功能，它自带 HTML 解析器，能定位到 Element，适合网页设计者。

系统自带

最后，不得不说，其实 Mac 系统自带的截图功能对付日常工作已经绰绰有余，截图质量更是没得说。再配上 Preview 做点简单的注释，80%的活都能应付。