iOS 10のSwift Playgroundsを自分のプログラムのテストに使用するには

iOS 10とmacOS Sierra (10.12)のパブリックベータが始まりました。
早速両方をインストールしてみました。

Appleの規約上、おおっぴらにパブリックベータの内容に関して書けないことになっています。
スクリーンショットとかバンバン載せたいのですが、そうはいきません。

なので今回は、パブリックベータプログラムに参加しているお友達に向けての発信です。

私がiOS 10で一番気になっているのはSwift Playgroundsです。
XCodeにもPlaygrounds機能は、2バージョンつくらい前から付いてきていましたが、iOS版はプログラミング教育のツールとして機能を強化して紹介されました（Appleのページ）。
準備された課題を実行するだけではなくて、一から自分で作ったプログラムのテストにも使えるはずだと、にらんでいました。

少し試してみたところ、次のような感じのコードで、汎用的な使い方ができそうなことがわかりました。
もっとスマートな書き方があるのかもしれませんが、まずは第一報として、共有します。

//おまじない
import UIKit
import PlaygroundSupport
//ボタン生成
var button = UIButton(frame: CGRectFromString("0,0,150,50"))
button.backgroundColor = UIColor.gray()
button.setTitle("Buttonテスト", for: UIControlState.init(rawValue: 0) )
button.setTitle("Buttonハイライト", for: UIControlState.highlighted)
//Live Viewに表示
PlaygroundPage.current.liveView = button

Swift Playgroundsでは、コード入力の際も、いわゆるインテリセンスが今まで以上に効いていてXCodeでコーディングするよりも気持ちよくできると感じました。

WWDC2016の感想

私の事前の願いもむなしく、今回のWWDCでは新しいハードウェアの発表は（まだ）ありませんでした。
4つのプラットフォームの新しいバージョンの紹介に終始したキーノートでした。
私が気になった点は3点です。

• Apple Watchのアプリ起動が7倍速くなる。 アプリ一覧はデジタルクラウンを押して出すホーム画面の小さなアイコンではなくて、Dockになる？ （現状のApple Watchユーザガイド）
• メモアプリのコラボレーション機能（一言だけ紹介されていました）。
• Swift Playground。これが単に課題を解くだけのアプリではなくて、自由に任意のコードでアプリを開発できるようになっていたら、いよいよセルフ開発が出来てしまいます。

WWDCは正に継続的にアプリを開発・保守している人たちに、必要なことを伝えるのが趣旨なので、ハードウェアの新製品は別途スペシャルイベントが開かれるのでしょう。

2つのSwift言語

ややこしいじゃないですか、Appleさん。
秘密主義を守り通して発表されたAppleのSwift言語ですが、Swiftというプログラム言語は以前から存在していたようです（そういえばどこかで聞いたような、既視感がありましたよね）。

AppleのSwiftのページでも、一番下に「Looking for the Swift parallel scripting language? Please visit http://swift-lang.org」って白状しています。
Wikipediaにも両方が載っています（ http://en.wikipedia.org/wiki/Swift_(parallel_scripting_language) と http://en.wikipedia.org/wiki/Swift_(programming_language) ）。

名前に関しては、Appleは他とよくぶつかりますね。

iOSのフレームワークを画面解像度非依存にするには

iPhone 5はうわさによると4インチの640x1,136（ほぼ16:9）のHDディスプレイになるとか。
iOSデバイスは現在、320x480、640x960、1,024x768、2,48x1,536の4種類もの画面解像度を持っていて、プログラマにとって大きな負担になっています。
いくらXcodeが使いやすいといっても、4種類サイズのUIWindowをそれぞれ作らなきゃいけない現在の状況は余りにも芸がありません。

ここに来て更に増やすことはあり得ないと私は考えます。
もし増やすとすれば、フレームワークを画面解像度非依存なものにすべきです。

こちらの記事「UIKit in 10.7?」 では古くなったMac OS XのAppKitの代わりにUIKitを載せる提案が出ています（逆ですが、類似の課題です）。
今回は更に踏み込んで、AppKitでもUIKitでもない、もしかしたらHTML5ベースの画面ツールキットが良いのではないでしょうか。
WindowsもWin32 APIからWinRTへ移行しようとしていますし、iOS上にはPhoneGapのようなHTML5ベースのフレームワークもあります。
それで物足りなければOpen webOSも使えるはずです。
もちろんApple独自のフレームワークでも構いません。
iOS 6では何らかの対処がなされることを期待しています。

iPhoneシミュレータでのアプリの実行環境

• $USER：Mac OS Xのログオンユーザ
• $PWD：/
• $HOME：/Users/$USER/Library/Application Support/iPhone Simulator/User/Applications/$UUID/
• アプリのUUIDはXcodeでビルドして実行するたびに変化する
• $HOME配下にあるもの：Documents/、Library/、tmp/、appl.app/

[2011-05-14] 2009年に記事を書いてからXcodeを更新していない (3.1.3) ので、いまは変わっているかもしれませんが...

• シミュレータでのユーザのホームディレクトリは、
  ~/Library/Application\ Support/iPhone\ Simulator/User/
  この下に、Media や Library や Applications がある。
• シミュレータでのファイルシステムのルートは、
  /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulatorX.Y.sdk/
  例えばこの下の Applications にi386用にビルドした？ アプリをコピーして実行することもできる。
• シミュレータ本体の起動は、
  open "/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone Simulator.app"
  

/Applicationsのアプリと、/var/mobile/Applicationsのアプリの出来ることの違い

/Applicationsのアプリで出来て、/var/mobile/Applicationsのアプリ（Xcodeで開発する一般アプリ）で出来ないこと。

• NSThreadは使えるが、popen()はPARENTAGE_FORK DENY 1のエラーで阻害される。やはりバックグラウンド処理はFrameworkの範疇のお行儀の良いものでないと許されない（ちなみにバックグラウンド実行のNSTaskはiPhone OSのFrameworkから元々外されている；参照noviさんのBlogエントリ）。
• Shellのターゲットは作成できるけれど、デプロイ時に実行権が外される（chmod -x）。

逆に、/Applicationsアプリで出来ないこと。

• Settings Bundleによるアプリ設定アプレットが効かない。一般アプリはplistを作成するだけで、設定アプリ（Preferences.app）に組み込まれた設定項目と画面を、非常に容易に生成することができますが、/Applicationsのアプリはこの機能を使えないようです。
• SpringBoardによるアイコンの自動iPhone化（rounded border と glossy effect) が利かない。一般アプリではべた塗りのアイコンを作成すれば済むが、/Applicationsアプリでは自分でアイコンのiPhonne化をしないといけない。（逆に、一般アプリでアイコンの自動いPhone化を抑止するにはInfo.plistにUIPrerenderdIcon属性を設定する。）

[2011-05-14] アイコンの自動iPhone化を追記。これが分からず、1週間くらい悩みました。一般アプリと/Applicationsアプリのアイコンpngを入れ替えたりして確かめました。

Xcodeで実機デバッグの初級編

XcodeのiPhoneシミュレータでの開発は、すんなりいきましたが、今回、実機デバッグを初めて体験しました。
Xcodeで [Device 3.0 - Debug] をターゲットに選んで [ビルドして進行] を実行すると、iPhoneまたはiPod touchの実機でアプリの実行が始まります。

デバッグモードでは通常より起動が少し遅いので落ち着いて待ちます。

下記3つのウインドウは、実機デバッグ中にいつでも開いておくと便利。

• [ウインドウ] メニューの [オーガナイザ] を開き、[DEVICES] から実機を選び、[Console] を選ぶと、何がおこっているのかのログが表示される。
• [実行] メニューの [コンソール]（またはメインウインドウのgdbのボタン）はgdbのコンソールで、アプリが落ちたときのステータスなどが表示される。
• [実行] メニューの [デバッガ]（またはメインウインドウの殺虫スプレーのボタン）はGUIデバッガで、コールスタックから調査したいプロシージャを選んで、ソースコードや変数を見たりできる。

シミュレータで一通りうまく動いても、実機では動かないケースがやはりあります。
私がいきなり経験したのは、
NSStringでstringByAppendingString: の引数がnilだと NSInvalidArgumentExceptionで落ちるケースと、
NSDateでdateFromString: でこちらも引数がnilだとEXC_BAD_ACCESSのシグナルで落ちるケース。