2023年9月9日土曜日

質問。SwiftUIがイマイチ流行らないのはなぜですか? 回答。使ってみればわかりますが、明らかに機能不足です ちょっと凝ったことをしようと思うと結局UIKitをラッピングしなければいけません。 質問。Appleは本当にSwiftUIを普及する気があるのでしょうか?まだまだUIKitに比べて出来ることも少なく、バグも多くないですか?

https://jp.quora.com/unanswered/Apple%E3%81%AF%E6%9C%AC%E5%BD%93%E3%81%ABSwiftUI%E3%82%92%E6%99%AE%E5%8F%8A%E3%81%99%E3%82%8B%E6%B0%97%E3%81%8C%E3%81%82%E3%82%8B%E3%81%AE%E3%81%A7%E3%81%97%E3%82%87%E3%81%86%E3%81%8B-%E3%81%BE%E3%81%A0%E3%81%BE?__nsrc__=4


回答。

 · 
フォロー

SwiftUIで検索

Indeed 9件

Green 3件

Wantedly 1件

まだ先な気がします

 · 
フォロー

プログラミング言語そのものをつくることは技術力に長けた個人にも可能ですが、それを広く普及させるためにはプラットフォーム、開発者ベースやIDEをはじめとした周辺のエコシステムが必要です。AppleはmacOSとiOS、それらの開発環境であるXcodeを通じて、言語の普及に必要な全てを持っており、これまでもgccを置き換えるコンパイラのclangなどを提供してきました。

当時のAppleの立場で考えると、他の言語ではObjective-Cで構築された既存資産を最大限に活かすことができず、一方でObjective-Cの文法は独特で、他のモダンなプログラミング言語と比べて開発生産性で劣っていました。Objective-Cで構築された資産を継承でき、GoやC#、Rustと同じくらい読みやすくて開発生産性が高く、Apple自身が手を入れることができるLLVMベースの言語としてSwiftを開発したのではないでしょうか。

 · 
フォロー
  • iOS専業なのでAndroidなんか相手にしていない。
  • 常にiOSアプリの最先端を走りたいからSwift以外を選ぶのはリスクがある。
  • クロスプラットフォーム開発ツールなんて信じていない。
  • 社内アプリ開発で、社内ではiOSデバイスだけ配備されている。
  • Swiftに投資しまくっている。
  • Swiftを使えという指示がある。
  • Android向けは別チームがやってくれる。
  • (Flutter採用しても一部はSwift/Objective-Cが必要な場合もある)

私は案件次第でどちらも使っています。

 · 
フォロー

全部のバグをとってたらリリースが遅れてビジネスが失敗するので、見落としているのではなく、検出した上で優先度管理してリリース後に修正するとマークしているものもあるでしょう。

買わせてしまえば、こっちのものであり、後で修正すれば利用者も大枚はたいているのでさほど離れないですからね(程度問題ではありますが)。そしてだいたいみんなが忘れた頃に、バージョンアップ(以下続く)

 · 
フォロー

iOSアプリ開発に限って回答しますが、iOSアプリはSwift以外のプログラミング言語でも開発可能です。Swift前の筆頭言語であったObjective-Cはもちろん、JavaScript、C++、C#、Dartなどなど、様々な言語で開発可能です。

ルールはあります。

  • Xcodeでビルドしたアプリであること。あるいはWebView(かJavaScriptCore)でロードしたJavaScriptコードで動作すること。
  • iOSが提供するAPIはSwiftあるいはObjective-C向けに提供されている。

上記を満たす一番簡単な手段がSwiftを選ぶことです。Swift自体は強力な言語ですからiOSアプリ開発するならまず検討します。しかし理由があってどうしても他の言語を使わざるを得ないのであれば、iOSとの架け橋部分だけはSwift/Objective-Cで書き、最終ビルドさえXcodeを通すようにすれば解決します。

例を挙げるとUnityはスクリプトをC#で記述します。Flutterはメイン部分をDartで記述します。しかしどちらもiOS向けのビルドを行う際はXcodeを使います。そしてもちろんApp Storeで公開可能です。

 · 
フォロー

現状でいえばSwift UIがリリースされて、年数がたっていないのでstoryboardの方が圧倒的に多いと思います。これから開発するのであれば、Swift UIの方が良いかもしれませんが、よほど簡単なアプリでない限りSwift UIだけでは完結しません。storyboardというよりもUIKitの知識も必要になります。

注意点があります。Swift UIも決して簡単なものではなく結構習得に難渋します。私はStarfordのオンライン講義をみてやっと基本的なことが理解できました。

CS193p - Developing Apps for iOS
Welcome to the website of Stanford University's CS193p (Developing Applications for iOS using SwiftUI). You'll find materials from past iterations of the course here, including the most recent quarter: Spring 2023 . For more, check out the About page.

ただしいくつかのアプリを開発中でまた計画中ですが、storyboardを使う気はしません。第一選択はSwift UIです。

Swift UIは宣言的なUI定義ですが、では手続き的な言語に比べてシンプルで保守しやすいかというと実践した感覚では、それぞれ強みと弱点があってどっちもどっちです。

ですがStoryboardに戻る気はありません。その理由は何かということに関してですが、それなりの自己分析と考察が必要になると思いますので今回は勘弁してください。

 · 
フォロー

SwiftUIとStoryboardですが、AppleはSwiftUIへ移行しようとしている以上、SwiftUIは無視できないと思います。

Storyboardは視覚的にUIが定義できて、その点では良いのですが、オブジェクトが多くなったりランドスケープとポートレイトに対応させたりし始めると、多数のオブジェクトを重ねて配置したりせざるを得ず、ごちゃごちゃにになって管理が難しくなってきます。

また部品毎に動作を確認することが難しく、Stooryboard上だけでは全てのUIを定義できず、実際に動作させなければ確認できないことが多々あります。

現在SwiftUIで開発していますが、かなり考え方を変えなければならず、慣れるまで時間がかかりそうです。

SwiftUIはコードを書いてCanvasにリアルタイムに表示させて確認していくので、部品毎に正確に表示させて確認できるので、部品ごとに完成度をあげて組み合わせることができます。

ベースはコードなので、定義の管理はStoryboardにくらべて圧倒的に楽です。Storyboardでは編集を繰り返すとゴミのような不要なオブジェクトが残ってしまうことが多く、不要なオブジェクト探すのも大変です(結局あきらめることになります)。

しかしSwiftUIのコードは宣言的(手順で定義するのではなく、形と場所を定義する)で、単純な画面の場合は、大変に分かりやすいです。ただし複雑な画面になるとやはり簡単ではありません。

ただしタップに対する反応を定義する等は、SwiftUIの思想は理解しなければならず、これが結構深く学習するのには時間がかかります。

SwiftUIについても私自身発展途上なので、言い切れないところや誤解している点もあるかもしれませんが、今のところのまとめとしては:

テーブルやリストから詳細に遷移するなどの大まかな部分の定義はSwiftUIを利用して一画面内の細かいUIの動作は、UIKitあるいはStoryboardを利用するという、ハイブリッドがよいのではと感じています。

0 コメント:

コメントを投稿