MOTO+4 Applocations のブログ

Vim、IT業界では「ヴィム」とよぶのですね。弊方、ソフト開発をしていますが、永く機械の業界にいるので全く知りませんでした。その前は、日立や本物( HP、同社は元々UNIXマシンのメーカです )のUNIX上で、本物の vi (正式名:ブイアイ)をつかっていました。キカイの業界で、vi を使う者はいません。「ブイアイエム」と心の中で読んでいました。

vi はマウスを使わないため、最も早くコードをたたき込めるエディタです。しかし手になじんてしまうと他のエディタが使えなくなってしまいます。電卓よりそろばんの方が早いように、、、

ということで、Windows 上でも .swift ファイル を、vim で開くことになります。しかし、そのままでは コードの要素種毎の色付けができません。vim は拡張子毎に色付け設定が追加できます。例えばA2L (ECUの適合データ構造の定義)の設定を作ったことがあります。.swift ファイル をなら誰かが作っていそうです。

.swift ファイルの設定一式が GitHub に置いてありました。TortoiseGit でチェックアウトして、vim の vimXX/ vimXX フォルダにコピーします。

おおさすが ブイアイエム!!

前記事では

iOS17対応の環境で、TestFlight で App Store へアップロードまでできました。iOS17が搭載できるiPhoneは高く、iOSネタの売上けからみまだそこまで出せません。ちょとどiPadネタが始まったので、抱き合わせで iPad 6世代にしてみました。Xamarin 上でビルドする上では、iPhone か iPad かの区別は見られなかったもので、、、

iPad 6th の4G(セルラー)モデルなら、中古で1万円台後半です。中古市場ではiPhoneより画面が割れているなど痛んだ端末が少ない。弊方はiPadネタでGPSが必須なので4Gモデルとしましたが、WiFiモデルならもっと安いです。

まずOSをアップデートします。 iOS ではなく iPadOS というのですね。

TestFlightアブリ をインストールして、アプリをインストールは特に問題なし。

アプリを実行すると、中央部分に配置され、周りはブラックアウトとなりました。Androidでは、タブレットなりに画面が拡大されますが、Appleはちがうのですね。それともXamarinの制約でしょうか? アプリ動作自体は問題ないようです。

Xcodeで作成したお試しiPadアプリでは、ちゃんと四隅まで表示されますね。

再度、Xamarin 上で iPhone か iPad かの区別はないのかチェックしましたが見あたらず、、、まさか未対応なんてことは、、、

まあ IOS17との疎通確認用としては、これでよいでしょう。なんとか Xデー に間に合いました。

もう一点問題が

外部テスター の iOS16 の端末では、iOS17対応以降の TestFlight の招待が来ません。

内部テスター の iOS16 の端末は招待が来ています。たまたまかも知れません。要経過観察です。

前記事では、

MAC Book 2015 の Xamarin iOS プロジェクトを、MAC Mini 2018 に移したところ、TestFlight で Build できたが App Store のアップロードで失敗しました。

他の方の Xcode でのWEB記事を拝見すると、移行前の MAC と、移行後の MAC の両方の プロビショニングプロファイル が必要みたいですね。 Xamarin でも同様でしょう。バンドルID を新しく生成して、新規プロジェクトとすれば簡単そうですが、リリース途上のアプリの場合、この問題を解決するしかなさそうです。

注意事項: MAC毎に証明書を生成する仕様は、’24.7月現在は無くなったのかしれません。同じ手順を採ると移行先MACの証明書にはマシン名が付与されませんでした。ついでに移行先MAC用に作ったプロビショニングプロファイルも認識されなくなりました。現在調査中です。もしも本当にApple側の仕様がかわったのならAppleはなんてひどい。Appleは開発者側への悪影響を考えないのでしょうか?

移行前MACの証明書をExportする

アプリに紐づく証明書は複数あります。どれが何の役割か、個人名と組織名で何故2つできているのか、理解していません。

• Apple Development ：個人名
• Apple Distrburtion ：組織名
• Developer ID Installer ：組織名
• Developer ID Application ：組織名

キーチェーンツール を開くと沢山あって何がどれなのかわかりません。自分の証明書のタブを選んで、無効なた証明書は掃除をした方がよいです。

対象の4つの証明書が見極められたら、キーチェーンツール にて .p12 ファイルにExportします。他WEB記事では、証明書そのもの.cer ファイルではダメと記載されていました。試したところ確かにそうでした。証明書一つについての手順は以下のとおりでした。

移行後のMACで証明書をImportする

p12 ファイルを 移行先MAC にコピーして、キーチェーンツール にのメニュー ファイル -> 読み込む を選択します。ファイル選択ダイアログから p12 ファイルを選択します。以下、5つの証明書の Import 途中の状態ですが、見た目、importしたのがどちらか分かりません。証明書をダブルクリックで開いて、タイムスタンプで違いを確認するしかないようです。

もしも読込が無反応な場合は、ツリーの「システム」を右クリックして「…ロック解除」をおこなってみてください。

VS2022 for MAC の認識状況

VS2022 for MAC で、ユーザ設定 -> Apple Developer アカウント -> 詳細表示 を開き、証明書の認識状況を確認します。「キーチェーンがない」がきえました。証明書はMAC 2台分で8個です。

TestFlgiht のバンドル設定も「配布(自動)」「App Store(自動)」となり、ビルド後、App Store にアップロードできました。

しかし、Ad Hoc の方はうまくいきません。自動は選択できるようになったものの、ビルドすると「自動はありません」と蹴られてしまいます。こちらは重要でないのでボチボチで、、、

App StoreへのUPまでできました。端末へのインストールにつづきます。

Swift : スズキの自動車、オートバイも製造しているメーカ故N/Aで良く回りそう。。。ではなくPG言語らしくない紛らわしい名前です。Xcodeのメイン言語、C#/Javaより少しシンプルでちょっとVB6っぽい感じもします。やりたいことからコードの書き方の解説、ゼロからの解説WEB記事は多数ありますが、当方は他言語と違うとこだけ端的知りたい。それらをまとめてみました。

特別な記号や表現

Framework(?)

大きく2つあるようです。100%互換は無いようで、WEB記事を見るときはどちらで書いてあるか確認する必要があります。

コード構造(SwiftUI)

• まず画面クラスがStructで始まり困惑する。class と同意と考えてよい模様。
• 行末の「 ; 」はない。
• 画面定義と処理部が混在する構造。
• 多重継承はできない。これは標準クラスを継承する際も同様。
• デリゲートはc#のとは全くことなる。クラスに別の機能をエクステンションするのに用いる。クラス継承に近い感じ。
• Namespace はあるのかよくわからない。
• if の {} は省略できない。
• switch は defalut 無いとビルドエラーとなる。その中身もないとエラーとなる。
• ++ は使えない。 += はOK。
• スクリプト言語っぽいが、文字列に数値を結合するときは明示的に変換( String(数値) )が必要。
• new は無い模様。
• try ～catch じゃなくて、do ～catch にして、ハンドル対象のメソッドに try つける。
• 初期化していないクラスメンバがあると、init() メソッドでエラーがでる。
• GUI名やインスタンスは無い。GUIに@State変数を割当て、その値の変化で動作を作り出す仕組み。
• よって変数値ドリブン的に仕組みとなっている。GUI操作がイベントハンドラ内で書けない場合がある。これに合わせこむため工夫と頭の切り替えが必要。
• クラス仕様がコロコロ変わり、下位互換性を保っくれない。ネット上のコードサンプルの5割は使えないと思っていたほうが模様。
• 旧来自分たちで仕向け専用にGUI操作共通を作込んでいたようなレベルの内容が標準クラス化されている模様。それ故、そのクラス仕様が理解が難しい。そのため何をするにも面倒が多い。
• cライクのfor文はない。
• 入力禁止はむ、.disabled(true)、他言語はenable=false なので逆である。
• Timer は、Viewを消去しても自動解放されない。他言語は自動解放されるが。知らずにほっとくとTimer動作が続いているので予期しない結果を招く。
• Internet接続有無を知るための NWPathMonitor はシュミレータでは正常動作したが、実機では不安定だった。
• 時刻のmsecの書式は、SSS である。Ex) HH:mm:ss.SSS
• fileへの .synchronizeFile は適当に間引かれる模様。
• fileを読むだけのとき、openは不要。fileのURLから直接変数に代入する。
• auto変数の未使用はしつこく警告されるが、クラス内privateメンバの未使用までは警告されない。
• 特定のコードの書き方をすると、フリーズしたかと思うくらいBuild時間が増える場合がある。
• ネット上のサンプルコードでは、デリケートをよく用いている。デリケートはややこし過ぎ、可読性も落ちる。デリケートを使わずとも実装できる場合もある。
• 外部ライブラリはメーカ公式でなくオープンソースが多い。適用するバージョンは吟味する必要がある。
• URLセーフの公式APIはない。
• アプリ終了を検知するには UIApplicationDelegate を使う必要あり。しかしXcodeから停止された場合はハンドルされない。
• バックグラウンド処理への移行検出は、いろいろな方法かネットで紹介されているが、App クラスの onChange イベント でいいみたい。
• TASK間の変数の排他制御は必要なのかよくわからない。コンパイラには怒られない。昔のVB6みたいな印象かと。
• Androidでいう intentService に相当するものが見つからない。画面と独立したThreadの非同期サービスが作れないのかも。

以下よく出るメッセージ

GUI仕様

• ボタンなど画面下に寄せたい場合、Spacerは便利だ。Xamarinには無かったような。
• スクロールバーの幅は変更できない模様。
• checkboxは、MAC OS のみで、iOS/iPadOS で使えない。
• 一画面のGUI数に制限がある。20個くらいでout。
• 上記GUIには、Tableの行列数はふくまれない。
• TextField にmaxLength がない。changeイベントで制限しないといけないらしい。他言語では普通にサポあり。
• TextField で半角に入力を制限するには面倒らしい。
• TextField の同一fontに対する適切な高さが、なぜか端末毎に変わってしまう。自動高さ調整はない。rtfなどを表示する場合は、余裕のある高さが必要。
• プログラム内から自viewを閉じる場合は、@Environment.dismiss を使用する。Hide や back はない。
• 前viewに戻らない画面遷移を行う場合は、body の先頭で、state変数の判定を追加し、そのifスコープ内で次の画面のインスタンスをcallする。とても気持ち悪い。

IDE

総じてKB配置の制約も含め、Windows PCからクロスプラットフォームで 使う方が効率が高そう。未だ理解不足ですが以下の課題があるようです。

• App Storeからインストールせず、xipをダウンロードすれば、複数のバージョンを1台にインストールできる。シンプルに。Visual Stduio は製品( Ex. 2022) において1つのみ。Androidは小細工すればできたとは思う。
• Visual Studio や Android Studio のように、画面を画面エディタで編集できない。Swiftエディタ側でGUI手入力する必要がある。(X-Windowが出始めの1990頃 OSF/Motif でGUIコードを書いていたころに比べればマシではあるが、、、VC++6時代MFCでも100%ではないが画面エディタで編集できた。イマドキ何故? ) 尚、Visual Studio で Xamarin / .NET MAUI を使用したときも同じ(これはMAC側に合わせたせいかな?)。しかしこっちは画面定義は別ファイル。
• GUIプロパティもSwiftエディタ側で手入力する必要がある。Visual Studio や Android Studio はプロパティウインドウで、全プロパティが表示され、そこを変更することができる。Visual Studio で Xamarin / .NET MAUI を使用した時は、これができるので、MAC上できないことではない。
• まず GUIを選択するToolBox をどこから開くの分からない。画面エディタの少し離れた右上隅の小さな「＋」をクリックするのですがこんなの分からない。 Visual Stduioも Adnroid Stduio もメニューや明らかに分かるアイコンやメニュー項目が設置されている。あえて隠している?

• GUIのプロパティが全てプレ表示されない。何のプロパティがあるか別で調べないといけない。
• ポチ「.」入力時の自動メンバ表示は一応ある。メソッドのcallingシーケンスまでは出ない。
• メソッドやプロパティのに、マウスオーバしてもヒント的なも、定数値、型などのが表示されない。
• 標準のメソッドやプロパティのヘルプは、左クリックメニューからメソッドの説明は呼び出せるがマウスを介すため、Visual Studio のF1ヘルプキーよりムダ時間食う。
• struct View名_Previews : PreviewProvider が自動生成されるが、ロジック部作成中にも常時Previews表示され邪魔である。画面設計がおわったらコメントアウトした方がよい。
• iPhone/iPadの実機デバッグ時、プログラムの起動は端末上手動で行う必要がある。Visual Studio For MAC では IDEから起動できる。停止は何故か IDE から可能。
• print()の出力先は、メニューview -> Debug Area -> Show Consol より開く。自動で開いたりしない。
• デバック時の Brakepoint の挙動が不正確。Visual Studio For MAC では正確なので何故。
• デバッグ時の Brakepointするとアセンブラ行で位置づけられる。callstackは表示されるが、swiftのコード行ははっきりと分からない。大昔のVC++みたい。VS も AndroidStdio も使用言語のコード行で位置づけられる。イマドキ不便すぎる。
• Eclipse や Visual Studio と同様に、コード間違いがリアルタイムにエディタに表示されるが、5～10秒遅れる。間違いを直す度に、その遅れ時間分、待たないといけない。さらにムダ時間を食う。
• デバッグ時、 iPad / iPhone とWi-Fiで接続可能。一度USB接続でXcodeに認識させておく必要あり。MACmini で Xcode を動作させ、リモート操作しているとき、手元に端末を置いておけるので便利。Xamarin も出来るようですが Microsoft の説明ページに飛ばされるので、読むのが面倒なので控えてしまいます。
• デバックでBreakして再開するとき、普通に右▲を押すとアプリ再起動されてしまう。メニューにはContinueがあるが、スタートとポーズが別ならポーズボタンを用意すべき。
• 画面ビューアがコケことが多々。表示のとても遅く負荷も高そう。グルグル状態も多い。不必要時は非表示にしておいたほうが良い。
• クラスリファレンスがブラウザでないのはよい。昔のMSDNドキュメントみたい。
• 日本語化されていない。分かってはいてもやはり目に入りにくい。
• vi modeが標準装備されている。VS for MACのプラグインは日本語入力が狂うが、こちらは割と大丈夫。 vi modeは対応しているのは基本操作程度で未対応が多い。
  • : w (上書き) 使えず
  • :行数(行ジャンプ) 使えず
  • ．(繰返し)使えず。これは大問題。
  • yw (ワードコピー)は使えたものの Word数yw (ワード数指定コピー)はできない。
  • undo( u と r )がとち狂う。
  • 行末でyw (ワードコピー)すると改行コードも一緒にコピーされる。本来VIと違う。
  • 検索 / にて上下keyでヒストリができない。
• 品質的には20年前のVisual Stdioのようだ。結構固まる。OSも固まる。Windows98のころを思い出す。
• デバッグ時、変数値を直接代入できない。”Edit Value“とメニューはあるが無反応。デバッガのコマンドラインで、”po 変数名=値“で入力する必要がある。
• 文字コード体系を指定できるよう一見できるが、UTF8に強制保存されてしまう。SJISはNGの模様。
• コードを更新しても、そのコードfileがビルトされない時がある。
• Archivesで公開用にビルトするときは必ずクリーンする。予期せずエラーがでる場合がある。
• シュミレータに緯度経度移動モード “City run” があるが緯度経度は指定できない。

気付いた制限バグなど

• i + Tab 入力したとき、””で囲った特定文字列があると、そちらにFOCUSが移動し、タブ入力ができない。
• Xcode 14.3 (Xamarinの最終互換版) は、MAC OS 14 では「最新バージョンにしてください」と怒られる。普通は上位互換あるハズ。まだVS2010でもWIn11で動くが、、、
• Xcode 15.1(MAUIの’24.5月時点での互換版) では、色テーマがエディタ部しか変わらない。
• #ifでbuild外にした場合、アウトコメントにした場合、breakpointを残したままにすると、brakeされる。
• ンドラインで、”po 変数名=値“で入力する必要がある。
• 特定の漢字が化ける。”生成”など。全く違うコードになっているらしく、Windows VS Codeでも修復できない。
• 日本語変換結果がキャッシュに残留して、狂ってときおり出てくる。
• コードに不都合があるとBuildエラーとならず、途中でダンマリとなる場合がある。

中々慣れを要します… 随時更新中です。

操作性の悪い3つ MAC + Xcode + Swift を組み合わせた時の生産効率は、Android の 2.5倍といった感じです。新たにこの組合わせでiOSアプリを開発をしようとして見積中の方は要注意です。

もしもSwiftが面倒、すぐに環境を整えられない、ぜひこちらよりご相談ください。ただし不確定要素が高く、まだまだ勉強中なので急ぎでない案件にかぎります。

Appleより、「‘24.4月29日にiOS17向けに App Store にアップロードするのは、Xcode 15 を用いなければならない」 と宣言がありました。こういうことは一年前くらいに言ってほしいですね。

Xcode 15の要件は、macOS 13以降。

弊方のMAC Book 2015 は macOS 12 までしかUPできません。

しかしmacOS12 では、Xcode14.2 までしかUPできません。

よって新しいMACを導入する必要があります。中古で買えそうリストアップしました。この年代になると、ストレージが基板直付けになっていて容量UPできないとのことで出荷時の容量が重要です。iOSシュミレータはとても容量を食います。 現在導入済みのMAC Book 2015 は512GB なのでそれはキープしたいところです。

512MBモデルは手がだせません。 MAC Book 2015 は Xcode 14 + VS2019forMAC + 各iOSシュミレータ で使用率は30%くらい。近々では256GBでもよさそう。

MAC Book 2015 から画面共有すれば画面とキーボードはあるので MAC mini でもよい。 最新OSにも出来きて、Xcode 16 まで使える可能性もありそうなので、MAC mini 2018 の256GB版 を入手しました。

写真でみるとカッコ悪いですが、現物は筐体のエッジもシャープで、キレイなアルマイトが施され感動します。このエッジは金型では成型できないので削りだしでしょう。実務には何も役にたちませんが…

OSは前オーナーさんが最新にしてくれていました。

取り急ぎ以下2つをインストールします。Xcodeが最新にできるので、Visual Studio for MAC も最新にできます。

• Xcode 15
• Visual Studio 2022 for MAC

この時点でのストレージ容量は、、、まずはしばらくは持ちそうです。

開発中のアプリをVS2022 for MAC にて TestFlight 用でビルドしてみるとエラーが、、、プロビショニングプロファイル てが当たっていないようです。VS2022上ではプロファイルのダウンロードは行ったのですが、、、

どうもプロビショニングプロファイルは Buildマシンにも依存するようですね。MAC mini にて証明書を生成し同プロファイルを追加作成してみました。この時、VS2022 の Apple Developer の設定をみますと、マシン名が2種類(青下線部)現れています。MAC Book 側の証明書はエラー(オレンジ部)が出ています。

MAC mini 側の「状態」が「有効」になったので Build を進めます。再び同プロファイルの選択でひっかかり、プルダウンから選択可能な以下の設定ですすめます。”iOS Team Provisionning Pro…“とは何だかは分かりません。 TestFlight用IPAは生成できました。

App Store にアップロードしてみましたが、、、うげげっ

WindowsではProjectフォルダを丸コピーしても問題ないですが、Appleはそうはいかないようです。

パート2につづきます。