IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→法人化(今年))

UIWebViewからWKWebViewに移行する際にハマること(特にCookie周り)

Qiitaに書こうかと思ったんですが、完全に理解できていない情報が多いため、ログとして残します。

 

Cookie周りが非常に厄介

UIWebViewとUIWebViewはCookieやSessionが同期されます。
iOS11以降において、WKWebViewとWKWebViewも同期されます(?)
iOS10以下において、WKWebViewとWKWebViewは同期されません。
iOS11以降においても、UIWebViewとWKWebViewは同期されません。

同期するためにおそらくこちらの方法を使うと思いますが未検証です。

WKWebViewでのSessionの共有 - Qiita

同期されるのかされないのか問題は未だ非常に曖昧です。
同期される条件やタイミングなど。

 

参考

WKProcessPoolが違ってもWKWebView同士のcookieを同期されていた - しめ鯖日記

 

バージョンアップでセッションが切れる

当然、UIWebViewをWKWebViewに移行すると、Sessionが切れるため対応が必要です。
対応方法は未検証。

 

iOS10以下ではCookieの取り出しが困難

これは調べると結構でてきます。ただ取り出し方はこれだというサンプルコードがありません。javascriptを使い強制的に取るしか無いようです。

 

Cookieの設定タイミングが妙

webページ読み込み終了した後Cookieを取ろうとして取れないことがありました。UIWebViewとタイミングが違う可能性があります。要検証。

 

Cookieの削除が厄介

普通に消えないようです。
ここが非常に詳しい。

[Swift]Cookieの削除|杏z学習帳

 

認証関係で少しハマる

ググれば出てきますが、Basic認証SSL

func webView(_ webView: WKWebView, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void)

こちらを使用する場合、UIWebViewのときとは処理の方法が少し変わります。

特に何もしない場合は

completionHandler(.performDefaultHandling)

を呼んでやります。呼ばないと落ちます(やめて!)

 

WKWebView操作に関するキーワード

WKNavigationDelegate ほとんどこれです
NSKeyValueObserving この2つがメインです
NSURLConnectionDelegate Auth関係で使う場合があります
WKHTTPCookieStoreObserver(これは動くのか不明)

 

 

罠だらけ!

WebViewアプリはiOS13,14対応で一回血反吐吐くかもしれませんねこれ。

 

何故こんなに厄介なのか?

おそらくですが、UIWebViewと、WKWebView(iOS10まで)と、WKWebView(iOS11から)の情報が混ざってるからです。

求人情報から必要スキルを洞察する(モバイルアプリ・iOS版)

求人情報や、エージェントからの会社情報というのは頻繁に曖昧なスキル要件で書かれています。原因はいくつかあります。

  • 書いた人がそれしか知らないから、その情報を書けばわかると思っている
  • 書いた人が技術者ではなく、伝言ゲームになる
  • 該当の技術者が居ない
  • エージェントがよく解っていない

もちろん不明瞭な表現をしている案件ほど危ないので、避けたほうが良いのですが、「別に曖昧なプロジェクトでもやっていけるよ」という人も居ると思います。

そんな時どう予想をつけるかという話。(iOS版)

 

基本的な求人

iOSネイティブ
Swift4
iOS11以降

こう書かれていれば8割くらいは一般的なiOS求人です。

 

ハイブリッドアプリ

例1
iOSAndroidの経験者

例2
iOSjavascriptの経験者

例3
モバイルアプリ経験者
javascript

 

このように書かれていたら、jsで書くハイブリッドアプリを疑います。
ReactNativeはReactNativeと書かれていることが多いので分かりやすいですが、たまに書いていません。

 

APIもやって欲しい案件


iOSPHP経験者

 

こういう書き方もあります。
PHPiOSを作っている案件を見たことが有るので、その可能性も無きにしもあらず。

 

Rx

大凡iOSネイティブの求人っぽいけど

RxSwiftと書かれていたらかなり別物のコードになっているはずです。

 

その他あり得るパターン

iOSAndroid両方やってほしい案件は見分けが付きづらいです。

Androidの方の求人に「Swift」と書かれていたり、iOSの求人の方に「Kotlin」と書かれていたりするともう確認するしかないです。

 

締め

自分ができる領域って割と狭いですよね。

無駄時間を取らないように、求人読解力を付けておきたいです。

実務におけるSwiftUI,Combine登場の影響(随時更新)

QiitaなんかではSwiftUIやCombineが活発で注目されています。
iOS界隈はAndroidやWebに比べて一歩慎重に進行しているらしく、先進的な人にとってはそれがもどかしいようです。

 

私はどちらかと言えばアーリーマジョリティーで、先進的なものを少し毛嫌いするタイプです。明らかに悪影響も見えてしまうので。
そこで実務的にどういうふうになるか?という観点で、分かり次第メモしていこうと思います。
(現状は大して調べられていません。半日程度)

 

 

SwiftUIを使うために必要な環境

Xcode11以上(2019/09/08時点でbeta)
iOS13以上(今月リリース)
MacOS10.15(2019/09/08時点でbeta)

 

Macは任意ですが、一部使用に制限が出るようです。
私はMacOSをbetaにすると仕事に影響が出そうなので諦めました。

 

iOS13以上は必須要件

つまり、iOS12を切れるアプリじゃないと使えないです。
2019/09/08時点で少し調べてみましたが

Twitter iOS11以上
Facebook iOS9以上
Yahoo iOS11以上
LINE iOS10以上

まあここらへんですよね。
多くのアプリでSwiftUIが使えるのはおそらく2年〜4年後です。iOS15か16の頃。
Swift2から4にあがるまで2年くらいなので、そういうイメージですね。
割と長いので慌てる必要はないです。

じゃあ勉強するにはどうすればいいか?といえば
iOS13以降のアプリを作るしかないです。

StoryboardとSwiftUIは混合できるか?

できるようです。
既存プロジェクトにSwiftUIを含めることもおそらく可能ですが、最低バージョンがiOS13以上でないとエラーになります。

 

多くのプロジェクトではSwiftUIとStoryboardのブリッジになる

約束された未来です。
Androidの方も今そういう感じですね。
SwiftとObjective-Cとのブリッジみたいなイメージでしょうか?
SwiftUIで覚えなければならないことが割と多いので、非常に高コストな期間が2021年〜2025年くらいまで続くと思います。
そういうとこやぞ。

新しくiOSを始める人はSwiftUIだけ覚えればいい?

まだNOです。
これが許されるのは2021年以降の新規案件くらいですね。

 

Storyboard,Xibは消滅する?

これはまだわかりません。
例えばObjective-Cはほとんど成りを潜めましたが、Xibはまだ生きています。

3年くらいで答えは出るでしょう。

 

 

一旦まとめ

先進的な人にあてられて慌てて勉強する必要は無いですが、スイッチングに関しては戦略的に動けるようにしておきたいですね。
私は本格的に覚えるのは来年にしようと思います。

それにしても新しく覚える人は何世代分の知識を覚えなきゃならないんでしょう?また参入障壁が高くなってませんか?

あと主流の方法がガンガン変更される中で、独自路線で作ろうとするのはやっぱり危険ですね。自己満足のために苦しむだけです。巨人の肩を信じましょう。

ちなみに私がSwiftを触り始めたのは2.2からだったと思うのですが、一番盛り上がっていたのはSwift1の頃でしたね。世間の加熱と実務には乖離があるので怖いです。

 

ITフリーランスの働き方パターン簡易まとめ

フリーランスとして面談した会社が多くなってきたので、働き方に関するよくあるパターンをまとめたいと思います。

 

常駐フリーランス

最も多いと思います。
働き方としては社員・アルバイト・派遣などと似ています。
労働時間は月140〜180時間といったレンジになることが多く、レンジを超えたら再精算です。見込み残業有りの社員(プロパー)似たようなもんですね。
じゃあどこにメリットが有るの?と言われそうですがそれは別のお話。

 

常駐+同期リモート

常駐フリーランスにリモートを混ぜたものです。
例えば週のうち3日常駐で2日リモートなど。
同期というのは、労働時間が常駐と合っているという意味です。例えば10時〜19時など。

 

常駐+非同期リモート+時間制

一部常駐しつつ、土日や夜にも稼働するタイプ。
こうなると労働時間は「働いた分」になることが多いと思います。

 

完全同期フルリモート

常駐フリーランスと働き方は似ていますが、出社しないパターンです。
労働時間はレンジになります。
遠隔地とかだとこれが多いです。

 

非同期フルリモート+時間制

持ち帰り案件であり、受託開発なのですが、契約が時間制だったりします。

 

非同期フルリモート(請負い)

完全に受託開発です。
こうなると法人が多くなるような気がしてしまいますが、実はクラウドソーシングは大体これですよね。

 

締め

これら全部の案件を経験してる人なんて激レア人材なので、大体の会社の担当者は、このどれかの契約形態が当たり前だと思っています。なのでフリーランス側が確認する必要があることが多いです。

オレ流プログラムは何故失敗しがちか?

anond.hatelabo.jp

b.hatena.ne.jp

 

プログラマーはより改善しようという気概に溢れた人が多いです。なのでプログラミングに慣れてくると、どうにかそれを改善しようと思うことがあります。
これは多分麻疹みたいなものだと思うんですが、20代後半くらいのそこそこデキる人でよく見かけます。たぶん中二病みたいなもんです。「俺が改善してやる」となるわけです。

 

しかし失敗する、なぜか?

経験的にそのアプローチは失敗します。
見事に失敗して途中でやめるか、押し通してぶっ壊れるか、本人は失敗したことに気づかないか、と言うケースが多いと思います。

原因は、改善対象となる課題は1つではないからです。

  • 速度、軽量さ
  • メモリ使用量
  • コードや設計の美しさ
  • 読みやすさ
  • 開発速度
  • 開発品質
  • 開発コスト
  • メンテナンス性
  • 継続性

多くのアプローチは、いずれかの課題を少し改善し、トレードオフとして何かを失います。その失ったものに対して注意が向かないと失敗します。

最も多いのは引き継ぎできない、しづらいコードができあがることです。本人にしか触れないというパターン。

 

失敗しないためには

まずどのような課題(パラメータ)がプロジェクトに存在するかを知らなければなりません。
そのためにはプログラミングだけでは不十分で、プロジェクト管理の立場や事業戦略の立場、チームビルディングの立場など、様々な角度からプロジェクトというものをよく知る必要があります。
その上で、該当案件の状況をヒアリングし、その方法を用いた場合、トレードオフとして失うものは何かを考え、理解する必要があります。

これらを突き詰めるとテックリードシステムアーキテクト、CTOの仕事の一部になってくるのだと思います。

 

もう一つの解

トレードオフでどのパラメータにも害を及ぼさない方法を見つけるのもよいと思います。
しかしこれは非常に難しいことで、一朝一夕にはできないのではないでしょうか?

 

やりがちなオレ流

我流とか・オレオレフレームワークが基本的に悪しき文化だ。というのは割とこの業界広まっていると思うのですが、新しいアーキテクチャーパターンや、デザインパターンには無防備だと思います。

新しいアーキテクチャーパターンやデザインパターンでも、このトレードオフは発生していて、何かを改善するために何かを犠牲にしていることがあります。何を犠牲にするかを慎重に検討し、わからなければ(チャレンジしづらい状況なら)諦めて普通に書くのが良いのではないでしょうか。

近況 生きてます

8月は1年で一番目まぐるしい気がするんですが気の所為でしょうか?

夏季休暇がいけませんね。

休みが増えたら仕事しますしね。

 

🤔

 

メインのお仕事を2件にする、という計画はまあまあワークしつつ有るんですが、今は色んな絡みで仕事が5件になっています。

そして3件は忘れた頃に仕事が振られます、こわい。

整理したいです。

 

9月にやりたいこと

Xcode11を触り倒したい

趣味のアプリをいい加減進めたい(=Laravel勉強したい)

フリーランスを悩ませる、インボイス制度について個人的メモ

ここが読みやすいです。

www.sumoviva.jp

 

フリーランスはどうなる?

消費税を払う課税事業者にならないといけなくなりそうです。

 

なんで?

現状:発注者は、フリーランスに払った消費税を控除できる

変更:発注者は、課税事業者に払った消費税を控除できる

非課税事業者(多くのフリーランス)に払った消費税は控除できないので、二重払い状態になる。
実質、非課税事業者は消費税を益税にできない感じですね。

 

いつから?

2023年10月からですが、移行期間が数年あり、実際は2029年10月からだそうです。

 

売上1000万円以上フリーランスの選択肢

特に変化はないと思います。

 

売上1000万円以下フリーランスの選択肢

  1. 課税事業者になって、簡易課税制度を使う
  2. 課税事業者にならず、益税を諦める
  3. 売上1000万以上になって有耶無耶にする

フリーランスエンジニア(年商700万円)の場合

1は、700万円*10%*0.5=35万円 なので、現状より35万円支払う税金が増えます(5%のダメージ)
2は、700万円/1.1=636万円 なので、現状より64万円売上が減ります(9.1%のダメージ)

 

まとめ

たぶん、法人化ラインが下がるんじゃないですかねこれ?

私は1000万超えてる上に法人化するのであまり関係がなかったりします。

 

参考

otihateten.hatenablog.com

 

結論

やだしにたい