今年の1月は自作アプリの開発に邁進できた一ヶ月でしたのでここでちょっとだけ振り返ってみます

先月は、緊急事態宣言を受けて、兎にも角にもほぼ毎日自宅で過ごしていました。勿論、食材の買い出しやちょっとした息抜きで外食する機会はありましたが、それ以外は大好きな旅行も控えて自宅待機モードの一ヶ月間でした。そんななか、じっと家に籠もるのも勿体ないので、昨年から継続している自作アプリの開発にメチャメチャフォーカスしてみた次第です。

そんなライフワークの成果として、先日ご紹介したiOSアプリの新作 (iOS自作アプリ 新作をリリース! お買い物 1.0 “買い物リストをスマートに管理、買い忘れをなくします”“)をはじめ、4本のmacOSアプリを昨日リリースすることができました。

今回のTALKでは、個人でアプリを開発してみて、どんな学びがあったのか、その辺りをざっとご紹介しようと思います。なお、新作のmacOSアプリ 4本については、明日から順に1本づつご紹介する予定です。

 

< やっぱりSwiftUIは最強の開発言語だと実感しました >

長年に渡り”Objective-C“という開発言語で自作アプリを作ってきた身としては、”Swift“と”SwiftUI“にシフトチェンジするまでの思い切りに結構時間がかかりました。でも、昨年の緊急事態宣言であまり余る時間ができたこともあって、ようやくそんな迷いを振り切って、新しい開発言語でアプリを開発することができました。

Swift“は、圧倒的にプログラムの記述量を最小化できる一方で、素人にはシンプル過ぎてちょっと難解なお作法もあり戸惑う場面がありますが、ま、全般的にスッキリとしたプログラムが書けるので、その分、メンテナンス性にも優れているように思います。

SwiftUI“は、最初のうち、こんなんでアプリが作れるのかなあ?と懐疑的なところからスタートしたものの、実際に何本かアプリを作ってみると、昔の”HyperCard“を思い出させるほど使い勝手が良いことに気づきました。”SwiftUI“は宣言する言語と言われていますが、この意味が分かってくると、一気に親近感が湧く素晴らしい開発言語だと思います。今回作ったアプリも、iOSアプリは100% SwiftUIアプリ、macOSアプリもUI周りはすべてSwiftUIで作りました。SwiftUIで作ったUIは、とにかく再利用性が高いので、マルチプラットフォーム対応は勿論のこと、新しい自作アプリを作る際にも流用率がとっても高くなります。macOSアプリの場合は、100% SwiftUIアプリを目指す一方で、macOS独自の自由度の高いUIは既存の仕組みを使わざるを得ないので、今回も1本辺りのSwiftUI度合いは全体の60〜80%ぐらいだったと思います。いずれにしても、今回のように短期間に4本のmacOSアプリを作れたのは、紛れもなくSwiftUIのお陰だと思っています。

 

< 日本向けのアプリでも英語のローカライズは気を抜かいでね >

macOS, iOSいずれのアプリ開発でも、英語を読み書きできることは最低条件だと思います。

勿論、ネイティブレベルである必要はありませんが、英語でプログラム関連のドキュメントがそこそこ読めて、アップルの審査時にレビュアさんたちと英語でやりとりできる必要があります。たまに日本語でもOKなケースはあるものの、レビュアさんからのレスはすべて英語です。

それと、開発したアプリは日本国内でのみ販売する場合でも、開発の過程では、英語でUIを作りつつ日本語のローカライズをする、といった流れが基本かと思います。そうなると、いくら日本語でアプリの説明文を書いても、アップルサイドでは英語版のアプリとしてテストしているようです。ま、英語を優先順位にしたマックでレビューしているので当たり前なんですけどね。

実はここが日本人の開発者にとっても盲点。自分自身は日本語でリリースするのでUIも誤字脱字がないよう気を付けますが、ベースになっている英語表記の部分に目が届かず、思わぬミスに繋がります。今回も、他のアプリで作った英語の素材を流用したので、日本語版では正しいアプリ名なのに、英語版は別のアプリ名のまま審査に出してしまいました。細かな箇所ならともかく、メニュー項目の表記だったりするとリジェクトされてしまいます。

余談ですが、アップル社のトレードマークがある表記にも注意が必要です。今回は、何気に普段から使っている”iCloud”をUIの一部に書いてしまったため、やはりリジェクトされました。

 

< macOSアプリ開発で最大のハードルはCrash Reportに尽きますね >

macOSアプリは以前何本も作った経験値があるので、開発言語がSwiftUIに変わったとは言え、大筋で地の利がある分、開発自体はそれほど面倒ではありませんでした。

ただ、今回開発した4本のうち、3本はアップルの審査で「アプリを起動したらすぐにクラッシュしたので、Crash Reportを添付しておくよ」というメッセージとともにリジェクトされました。ちなみに、残りの1本は別の理由でリジェクトされました。

個人で開発しているとは言え、開発してバージョン 1.0が完成した後、2〜3週間ぐらいはフィールドテストをして、出来るだけのバグフィックスはしているので、アップリの審査に出す時点ではかなり自信があるのですが、リジェクトのメールが届く度に、「え?なぜなの?」といった思いになります。これだけテストしてのに、なぜアップルのレビュアが使うと、起動直後にクラッシュするのか??

その理由は、アップル社のレビュアさんたちはプロ中のプロのテスターだからです。今回の場合を例にとると、アップルではネットワークをオフにしたテストをしたり、個人の開発者には難易度が高いまっさらの環境で起動するからです。後者の例を補足すると、個人の開発者は、複数の開発環境を十分に用意できないなか、初めてユーザがアプリを起動する場面を見落としがちになるからです。開発者は、段階的にアプリに肉付けをしていくので、うっかりまっさらの状態でのテストを見過ごしてしまいがちだからです。

iOSアプリの場合は、iOSのバージョンを絞り込めば、個人の開発者でもiPhoneを2台、iPadを1台ぐらい用意すれば、完成度の高いアプリを作り易いんですが、macOSアプリはとにかく自由度が格段に高い動作環境下でのテストなので、専任のテスターがいない個人の開発者では、すべてのケースを用意できないという現状があります。

そんななかで、アップルがフィールドバックしてくれるCrash Reportが実に難解で、クラッシュの原因がとても難しいです。と言うか、Crash Reportをそのまま読んでもチンプンカンプン。

今回、3本のアプリでCrash Reportが届いたので、これはマズイ!という思いで、打開策をネットで検索しまくりました。

で、たどり着いたのが”MacSymbolicator“という神アプリです。世の中の人は気軽にどんなあぷでも神アプリっていうけど、このアプリこそ、開発者にとって救世主的なアプリです。

このアプリは、アップルから届いたCrash Reportと、アップルの審査に提出したアプリから抽出できる”DSYM”ファイルを画面にドラッグ・アンド・ドロップするだけで、

何と、クラッシュした箇所を示すプログラムの行数をピッタリ教えてくれます。

このアプリのお陰で、指定されたプログラムの1行をじっくり見つめつつ、アップル側ではどんなテストをやったのかを想像すれば、プログラムの改修方法がバッチリ変わりました。お陰で、翌日、アップルに再申請して、無事、承認してもらうことができました。

以前紹介した”SimPholders” (“アプリ開発作業でオススメなmacOSのユーティリティソフトたち “SimPholders” “Plane Pasta” “Cloud Battery” “Pixelmator Pro”“)と合わせて、手元に持っておくと、開発作業を大幅に時短できることは間違いないと思います。

 

< これからアプリ開発に挑戦してみたいと思っている方へのアドバイス >

通り一遍な言い方になりますが、兎にも角にも習うより慣れよ!と実践すべきです。

勿論、基本的な学習は不可解な努力だとしても、いつまでも勉強ばかりしていても技術力は決して身に付きません。ある程度の基礎を勉強したら、何でも良いのでアプリを作り始めてみることです。

そんなことを言うと、何を作れば良いか分からないと言われそうですが、普段、こんなことができる機能があったら良いんだけどなあ?とふと思ったことをアプリという形にしてみれば良いと思います。POOHの場合は、殆ど、このアプローチでアプリを作り始めます。

 

それと、先人の経験値を吸収することが重要なアクションのひとつです。企業で仕事している方は周囲の人たちからのアドバイスや指摘を参考にできますが、個人の場合はそんな機会がありません。POOHの場合は、毎朝、” Qiite“で興味があるジャンルの掲載記事に目を通すようにしています。この活動が結構役に立っています。

加えて、”GitHub“で公開されている膨大なソースコードも、開発作業に大いに役に立ちます。

 

後、アイコンやUIで使うパーツを自分で作るのは無理!という方が多いと思います。POOHも決してグラフィック系作業が得意ではないのですが、”flaticon“を年間サブスクリプションすることで、いろいろなアイコンを拝借しながら加工を加えて使っています。POOHの場合は、アプリのアイディアが浮かんだら、まず最初にアイコンを作ってみる派なので、こういったサブスクサービスはとても有り難いです。ちなみに、アイコンを使うだけなら無料なんですが、そのアイコンをアプリに組み込んで公開する場合は著作権的にサブスク契約がマストになります。その点、ご注意下さい。

多少の出費はかかりますが、著作権を考慮すると、そのぐらいの負担は覚悟すべきです。アイコン以外にも、素材を販売するサイトはたくさんあるので、開発者のニーズに合わせて調べてみると良いと思います。

それと、アップル社が”SF Symbols“というアプリで、UIで使うグラフィック系素材を簡単に組み込めるようにしてくれたので、アイコン以外のUI部品ならこのアプリで十二分に対応可能だと思います。POOHも、アプリ内のUIで使うアイコンイメージは、すべてこのアプリから選んで使っています。

 

そんなこんなで、自粛モードにあるいまこそ、プログラム開発に目覚めるべきタイミングだと思います。

老若男女問わずに、是非、この機会にチャレンジして下さいね!!

 

ホームページ “THE POOH FILES”にも是非お立ち寄り下さい。
Adobe Stock“でベストショットな写真素材を販売中です。是非ご覧下さい。
自作のmacOSアプリはこちらでチェックしてみて下さい。
自作のiOSアプリはこちらでチェックしてみて下さい。

tomohiko

長年に渡りMacintosh向けの自作アプリを作り続けているPOOHです。最近はiPhone,iPad向けアプリ開発にも挑戦中。グルメ、旅行、露天風呂、写真、サイクリング、映画、STAR TREKが大好き。レトロでSFなおもちゃを大量にコレクション。プレーリードッグと同居中。

おすすめ

コメントを残す