Mobile

This article highlights three technologies that you can combine to create a super-app: Flutter, Firebase, and Codemagic. Our task is...

This article is written by Daria Orlova. Code review is a widely adopted approach in the world of software development....

Apple is deprecating Xcode 12. What does this mean for you? Apple recently announced that starting from April 25, 2022,...

In the development world, it’s very common for technologies to be rapidly updated to introduce new features that improve the...

This article is written by Andrii Khrystian who has worked as an Android developer for about 10 years and has...

​​ iOS用のアプリは、macOSから開発・配布するのが理想です。iOSプラットフォーム向けのアプリ開発は、macOSなしでは考えられません。しかし、React NativeとCodemagicを組み合わせれば、macOSを使わずにiOSアプリを開発・配布できます。本記事では、Macを使わずにiOSアプリを開発・配布するための設定を行います。Linuxを使用し、Codemagicでカスタム/手動コード署名を行います。 本記事はSneh Pandyaさんが執筆いたしました。 LinuxでのReact Nativeアプリの開発 2015年以降、React Nativeはモバイル開発者に広く採用されており、その人気はますます高まっています。React Nativeは、クロスプラットフォームのモバイルアプリケーション開発フレームワークで、1つのソースコードからiOSとAndroidのアプリを開発できます。 React NativeはJavaScriptをベースにしており、ウェブ開発者にとってはチャンスが広がります。なぜなら、React Nativeを使ってモバイルアプリの開発もできるからです。iOSアプリを開発する上での最大の障害は、開発・配布する際にiOSのネイティブコンポーネントとmacOSが必要なことです。しかし、React Nativeの登場により、macOS環境に完全に依存することなく、iOS向けであってもアプリの開発・配布が可能になりました。 ​ LinuxでReact Nativeアプリを開発する方法 iOSアプリは、React Nativeプラットフォームを利用して、Linuxから構築・公開することができます。本記事では、ReactNativeAppSigningというプロジェクトを使用します。このアプリでは、React Nativeを使ってLinux上でAndroidやiOSのアプリを構築する方法をご紹介いたします。注意すべき点は、LinuxはネイティブにiOSでアプリを作ることができないことです。したがって、Androidアプリが作られ、同じコードベースを使って、Android版と比べて最小限の変更でiOSアプリを生成し、デプロイすることになります。進め方は主に3つあります：...

本記事はChris Raastadが執筆いたしました Firebaseは、モバイルアプリの開発と管理を簡素化するための、Googleによるクラウドベースのサービス群です。Firebase App Distribution は、アプリ開発者がAndroidとiOSの両方のビルドを1つのプラットフォームでQAテスターに配布できるようにするものです。このため、Flutterのようなクロスプラットフォームフレームワークでは、両方のプラットフォーム用にQAビルドを一箇所にまとめておくことが理想的です。 本ガイドでは、Firebase App DistributionでFlutterアプリのAndroidとiOSのビルドをテスターグループに簡単に配布する方法をご紹介いたします。 前提条件 本ガイドに従うには、次のものが必要です： FirebaseでQAに配布したいFlutterプロジェクト Firebaseコンソールでのあなたのプロジェクトへのアクセス（存在しない場合は新規に作成します）。 Firebaseのアプリ配布プロジェクトにiOS用とAndroid用のアプリを1つずつ追加（存在しない場合は新規作成） アプリテスターの各グループ用に作成されたテスターグループ（Firebaseコンソールのアプリ配布テスター＆グループ（App Distribution Testers & Groups）セクションで作成できます） ビルドをインストールしたい各iOSデバイスについて、Apple...

執筆者、Rudrank Riyam。 Appleシリコンプロセッサーは、デスクトップCPUの世界に革命を起こしました。Intelのx86_64アーキテクチャからAppleのarm64への移行は、パフォーマンスを大きく落とすことなくx86_64コマンドをarm64に変換する、ロゼッタ2エミュレータのおかげで、消費者にとってとてもスムーズでした。しかし、2020年末に新アーキテクチャがリリースされた当初は、開発者たちもエミュレーションに頼る必要がありました。というのも、開発者ツールやライブラリの大半は、arm64アーキテクチャをサポートしておらず、さらにそのために、パフォーマンスが不安定になったり、場合によってはクラッシュしたりすることもあったからです。 新しいAppleシリコンチップが登場して約2年が経過した今、状況は一変しています。arm64アーキテクチャへの移行がまだの方は、この機会にご検討ください。昨年や2020年末と比較すると、ほとんどの依存関係やツールが新しいアーキテクチャに対応しているので、移行作業中に大きなハードルに直面することはないでしょう。 さらに、皆様にご愛用いただいているCI/CDプロバイダーであるCodemagicが、初のMac mini M1ビルドマシンを一般公開したことにも触れないわけにはいきません!　すでに一部のお客様には、新しい効率的なチップを搭載した強力なビルドマシンをお試しいただき、ビルドタイムの大幅な短縮に成功されております。そこで、IntelからM1への移行、つまり、プロジェクトのCI/CDパイプラインを、古き良きx86_64からピカピカの新しいarm64へ移行することについてご説明させていただきます。 本記事では、以下のトピックについてご紹介いたします： 必要条件 新アーキテクチャでの作業 サードパーティの依存関係を更新 Mac mini M1とMac Proのビルド時間 それでは、さっそく始めましょう！ M1への移行に必要な条件 本稿執筆時点では、ワークフローをCodemagic上の新しいApple M1仮想マシンに移行するには、**Xcode 13.3+**を使用する必要があります。これは、macOS...

Written by Rudrank Riyam. Apple silicon processors are a revolution in the world of desktop CPUs. The transition from Intel’s...

本記事の執筆者はMina Pêcheuxです。 大規模なUnityプロジェクトに取り組めば取り組むほど、小規模なUnityプロジェクトに取り組んでいるときには考えもしなかったような、堅実で、長期的なプロジェクトを構築するための基本的な専門領域がいろいろあることがわかります。特に、ユニットテストは、複雑で少し退屈な場合もありますが、必須です。ユニットテストでは、コードベースを小さな論理ユニットに分割し、それぞれがきめ細かく動作することを確認することで、アプリの強固な基盤と、コードのリグレッション（機能後退）を回避することを保証できます。 ですが、ユニットテストを設定して自動的に実行させるのは、Unityではかなり厄介な場合があります。そこで今日は、Codemagicで構築したCI/CDパイプラインを使って、Unityでユニットテストを作成し自動化する方法についてご説明いたします。 そこで、本記事では以下について学べます： 効率的なアジャイル開発に自動ユニットテストが必要な理由。 Unityでユニットテスト自動化を設定する際の問題点。 サンプルプロジェクトとして使用する、基本的なPongゲームの作成方法。 Pongゲームのユニットテストを設定する方法。 Unityプロジェクトのユニットテストとビルドを自動化するためのCodemagicの設定方法。 それでは、まいりましょう！ DevOpsと自動化 “DevOps”とは、「開発」と「運用」（operations、“ops”）を連結させた言葉で、様々なことを表現できるふわっとした言葉です。例えば、チーム（DevOpsチーム）、一連の慣行や哲学など…。全体としては、開発とITの世界の最良のものを使って、より良いコードを生産し、*簡単かつ継続的にリリースを提供する**ということです。 DevOpsは、例えばウェブ開発者がよく従う哲学です。大きなオンラインプラットフォームで仕事をする場合、定期的に新しいバージョンを出荷し、顧客のためにソフトウェアをアップグレードする必要があります。オンラインサービスなので、基本的にはコンピューターのどこかにあるソースコード（どんなクラウドも他人のコンピューターに過ぎないことは周知の事実です）を最新のアップデートに置き換えて、新しいリリースを公開する必要があります。 ですが、大きなバグを公開したり、間違ったコード行のためにインフラがブロックされるのは当然避けたいものです。また、新しいものをリリースする頻度を考えると（それが大規模なリファクタリングであれ、非常に小さなバグ修正であれ）、バグに対するテストと公開のすべてを 自動的にできれば最高ですよね？　 それが、DevOpsの核心的な関心事の1つであり本質です。つまり、継続的インテグレーションと継続的デリバリー、またはCI/CDです。これらは、従来のソフトウェアエンジニアリングにおける重要なプロセスで、バージョン管理ツールとともに製品のデリバリーを自動化するのと同時に、このデリバリーが何も問題を起こさず、ダウンタイムを生じさせず、迅速な修正を必要としないことを確認することを目的としています。 だからこそ、ユニットテストはDevOpsと自動化のための基本概念なのです。つまりこれは、リリースするコードが有効であり、リリース時に製品をクラッシュさせないことを保証するため、この自動化のチェーンにおける重要なブロックの1つとなっています。そのため、CI/CDプロセスでは通常、ユニットテストが必須ステップとしてどこかに組み込まれています。基本的に、ユニットテストが失敗した場合、デリバリープロセスは中断され、バグのあるバージョンはリリースされません。 Unityと自動化 Unityの必要最小限のCI/CDツールの問題点...