SwiftUIアプリを24時間で作ってリリースするひとりハッカソンの結果報告 | TOKOROM BLOG
2019年はSwiftUI誕生の年 2019年のSwiftUIの発表はたいへんインパクトがありましたね！ Objective-CからSwiftへの変遷と同様に、ここ数年で間違いなくSwiftUIがiOSアプリ開発のスタンダードになるものと思います。 いっぽうでSwiftUIはまだまだ機能不足、情報不足で実際にリリースする案件に適用するには心許ないというのが2020年1月時点での現状です。特に自社のメインサービスやクライアントワークでSwiftUIの導入を決断をするのはなかなか難しい時期かもしれません。 また次の6月のWWDCでアップデートが発表され状況は変わってくると思いますが、それを待つのも… ということでハッカソン ということで、冬休みにひとりでハッカソンを実施して、 24時間でSwiftUIでiOSアプリを開発して AppStoreでリリースする ところまでやる！ということにしました
これがXcodeでのバージョニングの決定版になるかも • Yuta Tokoro
概要 この記事でできるようになること 安定してInfo.plistの内容（ここではBuild番号）を変更できる ふつうにRun Scriptで編集するとタイミングによってすぐにアプリに反映されないことがあったりしたがそれが解消される Info.plistに差分がでないのでcommitのときに邪魔にならない なお、この方法を教えてくれた熊谷さんがこの方法に行き着いた経緯や所感がこちらに詳しくまとめられています。詳細や考え方などをきちんと知りたいかたは是非、熊谷さんの記事をご一読ください！ 必要な設定 Preprocess Info.plist file でInfo.plistをビルド前に確定させる Run Scriptで${TEMP_DIR}/Preprocessed-Info.plistを編集する 以下、具体的な話をします。 経緯 これまで、 デバッグ用やArchive用のアプリのバージョ
Objective-Cで非同期処理のテストをシンプルに書く方法 | TOKOROM BLOG
非同期処理のテストってどう書いてますか？ 標準のXCTest自体がサポートしていれば良いのですがそうではないので、非同期処理のテストを書きたい場合には、その仕組みを自作するか出来合いのライブラリを利用する必要があります。現実的な選択肢としては、 GHUnitやKiwiなど非同期処理をサポートしたテストフレームワークを利用する GHunitの非同期処理のテストの仕組みを真似て抜粋したライブラリを利用する（意外とこれが多いかも？） expectaなどのマッチャーライブラリに付属の非同期処理の仕組みを使う となるかと思います。 ただ、私が調べた時点だとどれもしっくりきませんでした。 まず、GHUnitやKiwiなどを採択している場合には良いのですが、非同期処理のテストを書くという目的だけのためにそれらのフレームワークを使うというのは冗長すぎます。 また、GHUnitの非同期処理の仕組みだけを抜き
Xcodeのプロジェクトファイル（pbxproj）がコンフリクトしまくるのをなんとかしたい！ | TOKOROM BLOG
2014/02/09 追記 コメントのところでやり取りしているようにmergepbxの作者さんから連絡があって、この記事で書いた問題が修正されました！ 今現在は merge=mergepbx がいい感じになってきているのでそっちがオススメです。 複数人でプログラミングしているとpbxprojがやたらとコンフリクトする 例えば、 Aさんが AALabel.m をプロジェクトに追加して Bさんが BBLabel.m をプロジェクトに追加して とただそれだけなのにマージのときにコンフリクトするpbxprojさん。。。 ただそれぞれファイルを追加だけのことでコンフリクトするなんて… どうにかならんもんかいとTwitterでつぶやいたところ、 @azu_re さんから有り難い教えが！ @tokorom gitはファイル別にマージ方法を指定できるので、mergepbxみたいなのをpbxprojのマージ
Objective-Cでカリー化とか部分適用してみる | TOKOROM BLOG
導入 会社でHaskell勉強会に参加して、カリー化とか部分適用のパートの輪読当番になったのだが、正直、輪読時点でもそれがなんなのかよくわかっていませんでした。 しかし、勉強会で参加者のみなさまに教えてもらった結果、カリー化とかがやっと理解できました！ ということで嬉しくなって先日寝るときに布団の中で「Objective-Cでもできるかなー」と脳内コーディングしてみた結果を実装してみました。 もう他の人がやってるかもとか、こんなん実装しても実際のところ使わないよねとか、そんなことはまったく気にせずです。 実際やってみたソースコードは こちら に置いてあります。 ひとまずのゴール カリー化して部分適用ができる状態までということで、Haskellのmapが実現できるところまでを目標にしました。 map (+3) [1, 2, 3] これです。 Objective-Cでは当然、空白区切りで引数を
iOSのライブラリだってTravis CIとかCoverallsとか使うべき | TOKOROM BLOG
今日はGithubに公開したiOS用のライブラリを Travis CI と Coveralls に対応した手順を紹介したいと思います。 なお、実際にこれらを適用して運用しているリポジトリのサンプルは、 https://github.com/tokorom/BlockInjection になります。 前提条件 GitHubを使っていること GitHubでなんらかiOS/Mac用のライブラリを公開していること Travis CI https://travis-ci.org/ 目的 公開しているライブラリの最新コードがきちんとビルドが通るものか、テストが通る状態かを明示できます。 iOS用のCI環境を用意するのは通常すごく敷居が高い（物理的にMacが必要）のですが、Travis CIはiOS/Mac用のライブラリのCIを無料で請け負ってくれるかなり太っ腹なサービスです。 事前準備 Travis
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
