ジョブズCEO退任


ジョブズがCEO退任の手紙を、Apple取締役と社員に送る

ついに来るべきものが来たという感じが。覚悟していたより早かったけど。

うちの会社、というよりも私個人の活動は、学生のときに初めてMacを触ってからずっとそれに支配されてきた訳で。いまの仕事をやれているのは、ジョブズのおかげといっても全然言い過ぎではない。

とりあえず思いつく言葉は、お疲れさまでした。かな。

MacでARMでUniversal Binaryの悪夢再び?


マイコミジャーナルより、『加速する「MacでARM採用」の噂、議論の存在をIntelが認める』。

マジすかー。PowerPCとIntelのUniversal Binary対応が終わったと思ったら、次はIntelとARMのUniversal Binaryすか。3つ同時にサポートすることは、共通して動くOS Xのバージョンがないから、考えなくてもいいな。

しかし、PowerPCからARMだったら、基本のエンディアンが同じだからまだ楽だったろうに。間にIntel挟むから面倒。ま、上位の方しか作らないアプリ開発屋は、あんまりエンディアンの影響受けないけどね。

iPhoneアプリでUDIDを使いたいケースその2


追記による注意:この記事は、はなはだしい勘違いに基づいていて、内容が破綻しています。修正しようにも、最も大事なところが勘違いしているためほぼ全部書き換えになってしまうので、しょうがないのでそのままにしておきます。最後に何が問題だったか書いておくので、そちらを参照して下さい。ということで、そのままの中身を信じないで下さい。

前回に続いて、iPhoneアプリでUDIDを使いたくなるケーススタディ。

あるiOSアプリがあったとして、自宅ではiPadの広い画面でゆうゆうと使いたい。通勤中はiPhoneで使いたい。それぞれのデバイスで、作業を別々に進めていく。どこかで同期を行う必要がある。こういった状況を考えよう。

まず大前提として、iOSのモデルは1アカウントに対して複数デバイスを運用する。これらのデバイスは、iTunesを通じてアプリおよび書類を同期できる。逆に言うと、複数デバイスで異なるデータを保持し続けることを想定していない。

もちろん、ほとんどの状況において、データの同期は善だ。iPhoneとiPadとで違うデータがたまり続けたら目もあてられない。そのためにiTunesを使ったり、同期のための独自サーバを立てたりする。iOS 5からはiCloudも提供される。

でも実際にアプリを使っていると、同期したくないデータも出てくる。たとえば、ブックビューワみたいなアプリを考える。iPhoneでもiPadでも同じ本棚を共有して本が読めるとする。このとき、iPhoneで呼んだ続きをそのままiPadで読みたい、という要求があるだろう。それと同時に、iPhoneで読んだ本はiPhoneで読み続けて、iPadではiPadのものを読み続けたい、という要求も発生するだろう。

現在の同期モデルだと、前者しかできない。すべての書類が同期されてしまうので、「前回読んだ本」を表すデータもただ一つしか存在できないからだ。となると、そのデータをデバイス毎にひも付けた形で保存しておきたいことになる。、、、UDIDさんの出番ですよー。

UDIDが使えれば、それをキーとしてデータを保存しておけばいい。生のデータを使うのが嫌であれば、ハッシュ値でも何でもとればいい。UDIDが使えないとなると、デバイスを識別する方法がなくなっちゃう。仮に自前のUUID作ったとしても、それがデバイス間で同期されたら意味ないし。

デバイスのモデル名を使うという方法があるかもしれない。UIDeviceクラスからは、@”iPhone”や@”iPad”という現在使っているデバイスのモデル名が取得できる。なるほど、これならiPhoneとiPadは識別できるな。、、、一人でiPad二台使ってたらどうすんの?

というわけで、やっぱりUDIDは欲しい。ま、これに関してはMACアドレスで代用は可能だけど。ネットにつながない「閉じた」アプリケーションであっても、複数デバイスを運用する限り、どのデバイス上で動いているか識別したい要求は存在する。

追記による注意:はい、どこが勘違いしていたでしょうか?「iTunesの同期によって、デバイス間の書類も同期される」というところです。実際は、同期されません。したがってUDIDを取得する必要もありませんでした。

もともとこの記事は、UDIDが必要になるケースって何があるかな?と考えて、複数デバイスを使い回しているときにUDIDを意識することがあるかも、というところから書いていきました。その結果、都合のいい勘違いを自分の中で作ってしまったようです。ということで、迷惑をかけた人がいたら、申し訳ありませんでした。

UIDeviceのuniqueIdentifierがdeprecatedに


iOS 5 beta 6で、UIDeviceクラスのuniqueIdentifierプロパティが非推奨(deprecated)になった。将来なくなるってこと。んな、beta 6まで進んだこのタイミングで言われても、という気はする。

uniqueIdentifierプロパティは、デバイス個体のID(UUID)を取得するためのメソッド。これを使うと個体を識別できる。値自体は特に秘密ではなくて、iPhoneをMacにつないで、iTunesを使って確認できる。個体識別番号っていうと、ちょっとでもIT系のニュースを聞きかじっている人なら、即セキュリティやプライバシーの問題を思い浮かべるよね。実際、UUIDを許可無しに流出させるアプリがあるってニュースもあったし、穴はふさいどけ、ってことなんでしょう。

開発側からすると、別にプライバシーを暴くためでもなんでもなくて、UUIDを使いたいっていうケースは存在する。それは実行環境の識別を行いたいから。もっと細かく言うと、デバイスの個体識別と、ユーザ識別がある。

デバイスの個体識別は、ユーザがアプリを複数のデバイス(たとえばiPhoneとiPad)で使っているとき、いまどっちのデバイスで動いているの?というのを知りたいとき。これをやるには、デバイスのUUIDが不可欠なんだよね。これが取れないとなると、MACアドレスを使うか、そもそも個体識別が必要ないように仕様を変えるしかない。

ユーザ識別は、いま使っているユーザを他のユーザと区別したいとき。これをやるにはUUIDは完全ではないんだけど、手軽なソリューションだった。

ユーザ識別をしたいときってのはIn App Purchaseが絡むときが多いので、そのAPIを使うこともできる。でも、あれを使うとユーザにApple IDの入力を頼むことになるんで、警戒されるんだよね。

まぁ、どっちにしろUUID以外のきちんとしたソリューションは考えておかなくちゃいけなかった訳で。今回は先延ばしにしていたものに対して、尻を叩かれたかって感じだ。 the domain shops

iPhoneアプリでUDIDを使いたいケースその1


iOS 5からUDID取得APIがdeprecatedになるぞ、ってのを受けて、どんなときにUDIDを使いたくて、その代替策はどうなるかというケーススタディ。

まずは、機能を制限解除型で購入するアプリ。あるアプリをダウンロードして、一部の機能に制限がかかっている。In App Purchaseで購入することで、その制限を解除することができる。これをどうやってアプリで管理する?または、悪意あるユーザのクラックからどうやって守る?

いちばん簡単なのは、NSUserDefaultsにフラグを設定すること。

[[NSUserDefaults standardUserDefaults] setBool:YES forKey:@"purchased"];

って感じでね。簡単だけど、初期設定のplistを書き換えることで、簡単に破られてしまう。

じゃあってんで、何らかの固定文字列のハッシュ値を書き込むようにしたらどうだ?これなら、もとの固定文字列がばれない限り破られない。これは、一度だけ誰かが購入して、そのplistをコピーすれば破られてしまう。CFUUIDでUUID作っても、同じ。そのもとのUUIDをどこに保存するの?ってことになる。

そこで、UDID登場。UDID + 固定文字列のハッシュ値を使うようにする。これならこの値が流出しても、同じUDIDを持つデバイスでしか使えない。少しまともになった。

この手法の問題点は、機種変更すると使えなくなってしまうこと。フューチャーフォンとは違い、iPhoneでは機種変更したら前のアプリが使えなくなってしまう、というふざけたことは許されない。これは、In App Purchaseを使っているときは、リストアすることで対応できる。

別の手法を検討してみる。キーチェーンを使う方法。キーチェーンの中に、購入済みフラグを設定する。いまのところ、これは使える。

問題点は、キーチェーンの中に保存した情報は、アプリを削除しても残ること。制限解除キーが永遠に残るのは気持ち悪い。あと、キーチェーンって基本的には、ネットワークサービスのパスワードのように、ユーザが何度も入力するのが面倒な情報を保存しておくものだ。つまり、ユーザがすでに知っている情報が保存されているっていうのが前提。制限解除キーみたいに、ユーザから隠したい情報を入れておくのってどうなのよ、という気はする。もしかすると、将来AppleがiPhone版のキーチェーンアクセスみたいなものを出してきて、キーチェーンの中の情報を自由に見れるようにするかもしれない。そうなると、お手上げ。

また別の方法を。今回はIn App Purchaseで購入するというのが前提なので、購入したかどうかの判断をStore Kitを使って行うことができる。iTunesのサーバにアクセスして、購入履歴をリストアすることで判断する。

これの問題点は、ネットワークアクセスが必要になることと、毎回ユーザにApple IDの入力を求めることになること。これはめんどくさい。また、Store Kitへのアクセスをユーザの操作無しに行うと、アプリ申請時にリジェクトされる恐れがある。Store Kitのアクセスは、アプリを削除して新規インストールした、バックアップもなくしちゃいました、というときに留めておくのが無難。

ということで制限解除の許可には、ユーザを識別できて、かつ書き換え不可能なIDが必要なわけで、それにはUDIDは手軽な手段だったんだよね。そういったIDは、他にはApple IDがあるけど、これアプリからは全うな手段では取得できないし。ユーザからアクセス不可な領域ってことでキーチェーンを使うってことになるんだろうけど、なんか不安があるんだよな。

iOS SDK 5 beta 6登場と、新OSへ対応することについて


iOS SDK 5 beta 6が出たという事で、絶賛インストール中。iOS 5もbeta 6まで到達したという事で、対応を行うアプリ開発側も本格化してくる頃でしょう。

新しいバージョンのOSが出ると、アプリ側の対応は大きく分けて2つある。一つは、新しいOSの新機能を採用する対応。やっぱり新機能はいち早く取り入れたいよね。この手の対応は、beta 1が出たらすぐ検討に入る。イケルかも?と思ったら、開発開始。beta 1から正式版リリースまでは、だいたいいつも二ヶ月くらいなので、それに間に合わせるのが必須。

もう一つは、既存アプリの動作検証。新しいOS上で、前のバージョンとまったく同じように動いてくれるかどうか、確認する。この対応は、新OSのベータ番号が上がってくれないと進めらんないんだよね。ベータバージョンが浅いうちは、Appleの問題なのか、こっちの問題なのか、よく分からない事があるから。ある程度こなれてきてから、一気に行う事になる。

新OSが出たら、昔のアプリは動かなくなるものなのか?動かなくなるのは、Appleのバグなのか?まー、これが何とも言えない。Appleのせいとも、開発者のせいとも、言い切れない事もある。

新OS対応で厄介なのは、既存のAPIの挙動が変わっている事があること。ドキュメントにも書かれずに。これ、たまにある。もちろん、追加された新規APIや、既存のAPIの引き数が変化したりしたものは、ドキュメントに書かれている。開発者側もすごく気をつけて、チェックを行う。

でもたまに、APIは変化しないくせに、中身の挙動が変わっている事があるんだよね。推測では、APIは変更せずに、実装のソースコードだけ変えたんじゃないか、って考えられるもの。これがくせもの。API変更してないから問題ないだろう、と思っていたら、なんかしらないけど動かなくなっている。がんばって調べてみると、微妙に挙動が変わっていて、それが影響したりする。

これ、一概にAppleが悪いとは言い切れないんだよね。APIドキュメントに書いてある通りには動いているから。ただ、ドキュメントに書いていない範囲の動作が、前のOSと変わっている。だから、別に嘘はついていない。素直にAPIを使っているアプリでは問題ないんだけど、ギリギリといろんな機能を追加していると、問題が出やすい。そこんところの見極めは、いつも難しいね。

あと、もう一つ厄介なのが、後方互換性の確保。iOS 5対応するには、iOS 5 SDKでビルドしないといけない。そのバイナリが、iOS 4以前でちゃんと動くか?ってのを確認しなきゃいけない。基本的には、iOS 5の新APIを使っていなければ問題ないんだけど、これもたまに落とし穴があったりする。

iOS 5対応で遭遇した問題は、まだNDAの範疇にあるはずだから書かないけど、そのうち改めて書くかも。

そうそう。Undocumented APIを使っているってのは、論外だよ。そんなことして、OSのバージョン上がるたんびにいちいち時間取られるのはバカバカしい。App Storeで配信するアプリでUndocumented APIを使うのは、リスクは高いし労力も多いから割に合わない。 nimbus cloud .

HMDTの最近の仕事


せっかくだから、いまHMDTで進めている仕事をちょっと紹介。

まず、「デジタル大辞泉」次期バージョン。大辞泉は年に3回程度辞書データがアップデートされるので、機能の方もそれにあわせて強化していく。

今回のアップデートは、前回のブックインタフェースほどドラスティックじゃないけど、また着実に進化していきます。

続いては、「iMandalArt」。これも次のバージョンの開発が続いている。こっちは、ドラスティックにいくよ!マンダラはいままでのものでも充分完成されていたけど、さらに新たな仕掛けを追加する。これがうまく機能すると、いままでiMandalArtの使いどころが分からなかった人も、また興味を持ってくれるんではないか。

マンダラは「脳の使い方」を効率よくするための道具。どこまでいっても終わりはない。

次に「uListening」。これはアルクさんといっしょに開発しているアプリ。HMDTのページでは紹介するタイミングを逃していたっけ。リスニングに焦点をあてた英語学習アプリ。iPhoneで効果的にリスニング学習を行うために、様々な機能をつけている。また、英語学習教材として名高い「English Journal」を完全収録したものを毎月発売。EJの電子書籍版が買えるのって、いまんとここのアプリだけかな?

uListeningも細かいバージョンアップを続けいている。こういった学習のツールとして使うアプリは、いかにユーザの思い通りに操作を受け付けられるかが肝。執拗に機能の修正と強化を続けて行くしかない。

電子書籍系も続いている。直近に出るものと、今年後半にかけて出ると予定されているものをあわせると、10本以上になる。もちろん、「オートマ本」を含めたHMDT関連のものも。この辺りは、iOS 5の登場をにらみつつ。

電子書籍も、テキストを表示するだけのものではなく、「直筆 坂本龍馬の手紙」みたいにiPadならではの見せ方を取り込んだものも作っている。ePubみたいなテキストを表示する電子書籍アプリが「ビューワ」としての性格が強いのに対して、龍馬みたいなやつは「アプリ」の側面が強くなる。どっちもありだと思うんだよね。

アプリ開発者としては、やっぱりアプリっぽい書籍の方が作ってて面白い。こう、従来の本ではない、新しい媒体を作っているんだ、っていう気持ちをビンビン感じるからね。開発者の見せ場も多いしな!

新規開発のものとしては、画像認識をメインに据えたものが動いている。iPhoneのカメラから画像取り込んで、それに画像認識かけていろいろ作業する、ってもの。なかなか難しいね。苦戦してる。でも、カメラ経由画像の認識って、iPhoneをリアルな外界と接続する唯一の手段じゃない。いままでiPhoneでの外との接続、っていうとネットワーク上の話ばっかりだった。でもあれって、やっぱりバーチャルだよね。リアルな外界との接続を考えると、画像認識はどうしても外せない。この技術をてなずければ、アプリはもう一つ別のステージに行くだろう。

おもてだって言えるのは、こんなとこかな。最近は、一度出したアプリをバージョンアップしながら長い期間開発し続けられるようになった。それだけ機能強化のネタがあるし、経営的にもそれで成り立っている。一時期は、使い捨てかっ、て思えるようなiPhoneアプリが乱立していたことがあったけど、それはユーザにとっても開発者にとっても良くないよね。数年のスパンでアプリのロードマップを考えたい。 ip analysis

HMDT Webページリニューアル&ようやくブログ化


さて。

いままでHMDTのWebページは、私mkino個人のWebページをそのまま拡張したものになってまして、日記みたいなものは書いてあるんだけど、知らない人から見ると、この会社何やっているの?というかそもそもこれちゃんとした会社のWebページなの?という状態でした。

そんな状態も嫌いじゃなかったんだけど、そろそろちゃんとした会社の入り口ページが欲しいよね、とか、いままで出してきたアプリをまとめておきたいよね、とかいうことを話し合いまして。ようやくちゃんとしたWebページを公開することができました!

トップページのイメージは、こんな感じ。

開発したiPhoneアプリを大きくフューチャーしたデザインとなっております。

あとは、プロダクトのページ、執筆した本のページ、いままで書きためたプログラミングテクニックのページ、対外的な活動をまとめたページ、会社概要のページ、などがありますよ。

プロダクトの紹介については、ちょっと考えた。うちの会社の活動っていまのところ、他の会社さんといっしょにiPhoneアプリを作ることがほとんどなんですよ。ということは、もうすでにそちらでアプリそのもの紹介はされているはず。HMDTのページにアプリの紹介文を載せても、同じものがもう一つできちゃうだけだよな、と。

むしろ、開発会社であることを全面に押し出した方がいいのではないか?実際に開発した時の苦労話とか、プログラミング的にここを見てほしいんだよね、ということを書いた方がみんな読んでて楽しいんではないか?というか、このページを訪れる人は、きっとそっちを求めていると思う。

ということで、プロダクト紹介のページに「Developer’s Voice」というコーナーを作ってみました。ここは、アプリ開発を担当した技術者たちが、開発者ならではの視点からアプリについて語る座談会を収録したものになります。間違いなくここでしか読めない話が満載ですよ。

まずは、デジタル大辞泉のDeveloper’s Voiceを公開しています。お楽しみください。

 

Developer’s Voiceの収録は他のプロダクトもやっていますので、順次公開していきますよ。

こんな感じでやっていきますので、よろしくお願いします。開発ネタとかも、変わらずやっていくと思いますので。ボチボチと更新していきます。 Virtual offices Cacerevede