
はてなキーワード:iOS 6とは
Appleマップ・Google Maps・Yahoo!マップ・Bing地図・HEREWeGo・Waze・ゼンリン地図ナビ・moviLink・Sygic・地図マピオン・乗換MAPナビ・MapFan・COCCHi・navico・スーパーマップルの地図を見比べて思ったことを書いた。
地図の正確性とかは使用する場所にもよりけりだから、あえて評価しない方向でいく。ただし最近のオンライン地図サービスは誤りを報告する機能がついていることもおおいから、証拠写真を撮影したうえでそれを使用するとよい。
なお、あくまで地図サービスとしての比較なので、地図アプリとカーナビアプリが別になっているものは、地図アプリのみで比較している。なお、一部スマホアプリ限定機能を比較にいれているものもある (各アプリ固有の便利な機能もあるので) 。
ラスター画像 (jpgとか) を使用した地図が一般的だった時代 (2012年) 、いちはやくベクター画像を採用したことから、当時先進的だった (いまではほぼあたりまえになった) 高精細ディスプレイとの相性がよく、うつくしい表示でみることができた。
あとベクター画像はラスター画像にくらべてデータ使用量がすくなく、MVNOの昼休みの時間帯でも待てば (けっこう待つが)地図が表示されたのもメリット。(当時のGoogle マップは通信速度がおそいといくら待っても表示されなかった いまはベクター化されており待てば表示できる)
※現在はAppleもふくめてオフライン表示に対応しているサービスがおおいので、MVNOの場合は事前にダウンロードしてから使用するのがおすすめ。(オフラインが日本だけ非対応のサービスは明記します)
そのかわり、iPhone 4・iPod touch (第4世代) には負荷がおおきく、アプリが強制終了してしまうこともしばしばあった。
...さて、本題にもどると、当時としては先進的だったが、いまはGoogle マップやさまざまな会社の地図サービスもまねをしたため、似たり寄ったりになってしまった。
ただ、アメリカの一部地域では超リアルな3D地図が使用できるのはメリット。仮に日本展開したらものすごいコストがかかるんだろうな...。地図サービストップレベルでのうつくしさなので、もしアメリカの地図をみる機会があればためしてみてほしい。
画面表示をすっきりさせる目的のためか、データ提供元の表示が地図モードボタンのなかに集約されている。Appleマップのベースとなっている地図はジオテクノロジーズ (MapFanの提供元で以前はパイオニアグループだった) 。10年前はゼンリン優勢だったけど、ジオテクノロジーズを採用している地図サービスもふえてきた。
いちおう交通状況 (事故や道路工事など) を報告する機能はあるが、ナビゲーション専用機のシェアが高い日本ではスマホナビはGoogle マップ勢が大多数のため、渋滞情報以外はほとんど役に立たない。
日本においては、交通機関地図の色が国産の地図サービス並みに色あざやかのため、交通機関で移動するならGoogleよりもこっちを推したい。
...ただし、ほんとうの鉄道初心者であれば、地図サービスよりもJR東日本アプリ (JR海・西と提携しているため東北から中国までの広範囲でつかえる) など乗換案内専門のサービスをつかったほうがよいだろう。というのも、乗換案内専用のサービスは、駅名ではなく最終目的地で入力すれば最寄り駅だけでなく最寄りの出口までおしえてくれるため。あとリアルタイムの走行位置を表示できるサービスもある。
どうでもいいが、レビュー機能は病院やクリニックなど、一部カテゴリでは使用できないようになっている (薬局はレビューできる) 。Googleがどのカテゴリでもレビューできるのとは対照的。
自動車での音声案内は "一時停止で右方向" といった、信号だけでなく一時停止標識も目印として案内される。なるほどと思った。
そのほか、"このまま信号を通過" "このまま出口を通過" (高速道路でJCの直前にICがある場合など) といった、実際に曲がるポイントの手前の分岐というトラップにひっかからないような配慮がされている。
Googleのブランド力だからなのか、圧倒的利用率となっており、iOS 6 (Appleマップ初搭載)から現在にいたるまでApp Storeの無料ナビゲーションランキング1位の座をほとんどゆずっていない。また、iOS 26.2からは (EUの圧力なのかはわからないが) ついにデフォルトのナビゲーションアプリをApple以外に変更できるようになったため、今後さらに利用率が増加することがみこまれる。
※iOS 26.2時点では、アプリのインストール・メール・メッセージング・通話・通話フィルタリング・ナビゲーション・ブラウザアプリ・翻訳・パスワードとコード・非接触型アプリ (タッチ決済のこと) ・キーボードのデフォルトを変更可能で、2026年1月現在はそのなかのメール・ナビゲーション・ブラウザアプリ・翻訳・パスワードとコード・キーボードをGoogle製に変更することができる。Googleアプリはほとんどつかっていないが、非接触型アプリだけはGoogleの参入につよく期待したい (Google Payに対応すれば楽天EdyとかもiPhoneに搭載できるのではとみている) 。
数年前、ゼンリンから独自データジオテクノロジーズに変更になったのは話題になったが、Appleとちがって圧倒的利用率により失われたデータの回復がはやかったというのも特徴だった。
圧倒的利用率とAndroid標準搭載 (デフォルト設定でGoogleに自動送信) という強みをいかした独自の混雑状況を提供している。そのため、いきたい施設が混雑しているときを避けるのに役にたつし、ほかの地図アプリでは表示できないような小さい道路の渋滞情報まで表示できる。
高速道路と一般道路をカラーで区別する手段がないのが難点。ナビゲーションどおりに走行するならそこまで気にすることもないが、ナビゲーションを使用せずに高速道路と一般道路をつかいわけたいならほかのアプリのほうがよいだろう。
徒歩や交通機関でルート検索したときの徒歩時間が他社より若干はやめに計算されているような気がする。とくに交通機関は迷わずにルート案内どおりに移動できる前提での時間計算になっているので、電車をあまり使用しないのであれば、乗り換え時間が表示された徒歩時間 +3分ほどの余裕があるかを確認するのがおすすめ。
計算が面倒ならJR東日本アプリなど乗換案内専用サービスで歩く速度を "ゆっくり" または "もっとゆっくり" に設定して検索することをおすすめする。もしくは後述のYahoo!マップなら交通機関ルートの初期設定が "少しゆっくり" になっている。検索するような人は乗り換え時に迷うこともおおいので、この初期設定は評価したい。乗換MAPナビも交通機関で歩く速度を選択できる。
あとは検索バーが上側なのもGoogleらしい (Chromeもそうだから) 。PCの操作に慣れてたまにスマホという人にとってはこっちのほうが逆に都合がいいのだろう。自分はジェスチャー操作に慣れたから下側のほうが都合がいいのだが。
あとスマホアプリで完全な全画面表示にする手段もない。Appleは検索バーだけ表示にできる、Yahoo!とマピオンは完全な全画面表示にできるから、ふだん全画面表示にしているとどうしてもGoogleの窮屈さを感じてしまう。まあ、Googleは世界最大の広告会社ということもあり地図にも広告を表示しているから、どうしても消せないという面はあるのだろう...。
Mapboxの地図が使用されているが、Mapboxはゼンリンと提携しているため、Google マップが独自ジオテクノロジーズの地図になったのを期にゼンリンにこだわる人からの利用がふえた。配色が濃いのが日本サービスらしい。
また、日本サービスならではの特徴として、地図の種類に "住所" がある。東京都町田市の境目を確認したり、北海道の市区町村のふりがなを確認したりするのに便利。
日本のサービスということもあり、渋滞情報はVICSを使用している。そのため、ナビゲーション専用機での走行データもしっかり渋滞情報に反映される。
オフラインでは "防災モード" という自宅や職場付近のハザードマップのみダウンロードできるので、AppleやGoogleのように任意の場所を指定してダウンロードするということはできない。旅行先ではオンライン必須ということは了承しておくこと。
アプリが2025年7月にサービス終了してしまい、現在はブラウザーからしか利用できない (よく使用するならブラウザーからホーム画面に追加という手もある) 。
日本においては (道路の線とスポットアイコン以外)ベクター画像がいまだに使用されていないため、高精細ディスプレイでは画質が悪く感じる。はやく対応して...。実際Windowsのフィードバックアプリのマップカテゴリーで高評価数を特に集めたのが日本の地図は画質が悪いという投稿だった。
Windows 7までのMicrosoftは日本ローカライズが丁寧だったのに (日本独自仕様のMSNもWindows 8.1でグローバル仕様に統合され消えてしまった) 、いまとなっては日本市場をあまり考えていないとしか...。Windows10でやっとMicrosoftIMEのクラウド候補に対応したのだけは評価したい。
航空写真は鳥瞰図モードがあり、当時としては高画質だったのだが、現在はほかの地図サービスも航空写真が高画質になったうえ、3Dモードで立体的にみることもできるようになったから鳥瞰図モードのメリットは減った。
PCにおいては、ルート検索はできるが、ナビゲーションはできない (アプリもそうだったからそういう仕様なのだろう) 。スマートフォンにおいては、Bing上では検索せず、デフォルトのナビゲーションアプリが起動する、特殊な仕様 (ルートを設定できても音声案内できない問題への対策と思われる) 。
なお、PCで検索する交通機関は鉄道のみ対応していてバスは未対応。
オフライン地図はそもそもアプリがサービス終了しているが、あった時代でも日本はダウンロードできなかった。
※日本は地図の権利の関係でオフラインダウンロードできないサービスがおおいため、一概にMicrosoftを責めることはできない。(この記事中では日本だけ未対応の場合はすべて明記します)
サービス自体は昔からあるものの、日本でのサービス開始が2024年という新参。日本では海外勢はGoogle一強みたいな状態でやってきたけど、はたして成功するのかどうか...。それゆえレビュー動画もほとんどみない。
地図の配色が全体的に淡めな傾向がある。10年前で淡めな色づかいだったAppleよりも淡い。濃いめのYahoo!とは対照的。すっきりした色がこのみならおすすめ。ただし新幹線は (淡めな地図のなかでは) びっくりするほど濃い色で表示される。地図表示を交通機関にきりかえて在来線と見比べてもなお濃い。
日本においては、ランドマークの3D表示がゼンリンの3D地図レベルでうつくしい。
Google同様全画面表示ができないので、検索せずに地図だけ見たいときはUIが邪魔に感じる。
駐車場所の保存が車 (自動車) ・自転車・オートバイそれぞれで保存できるため、車と自転車をつかいわけているなら便利。自分は運転免許をもっていないし自転車も運転しようとはおもわないため (個人的には自転車も免許制にするべきだと思う法律と実情があっていないから) 、どれも使用することはないだろうが...。
ナビゲーションは徒歩で使用する場合、歩く速度を自分で設定できる (初期設定はやや速いになっている) ので、Googleみたいにせかせか歩く前提の所要時間表示に悩まされることがない。
自動車ナビでは駐車場からの徒歩ルートを提案する機能もある (自動車はもっていないので日本で機能するかは不明) 。あと自動車をオートバイに設定できるので、規制を回避したルートで案内できる。
※Google Mapsのナビだけを頼りに二輪車走行はやめましょう (二輪車規制に対応しないため) 。HEREWeGoのような二輪車規制に対応したアプリでも、念のため実際の標識を確認しながら走行するようにしましょう。
あと海外製アプリとしてはめずらしく、一時停止標識の警告機能がついている (ナビゲーション中のみ有効) 。余裕をもった減速に活用してほしい。
交通機関ルートは項目としてはあるのだが、"この機能は、ご利用の地域ではまだ利用いただけません。" と表示される。日本は世界的にみても交通機関がよく使用されるので、はやいこと対応されるといいな。
オフラインはボタンを押すと "日本で本アプリをご使用の場合は、オンライン状態を維持してください。" と表示される。前述のとおり権利問題はあるだろうが、マップとしての出来はいいだけに残念。
記事が長くなりすぎて文字数制限にひっかかったためanond:20260201122950 に書いた。
anond:20260202081917 に書いた。
iPhone Xでは昔のように、アプリのカードを長押しして出てくるバツボタンを押して強制終了になってて、これはすごく正しいデザインだと思う。だって強制終了っていうのは基本的には避けるべきことであって、iOSではそれほど大きな問題にはなりにくいとはいえ、うっかり強制終了してしまうような事故は避けたい。(ちなみに、アプリを強制終了するとバッテリーが長持ちするというデマがあるが、iOSの仕様をある程度知っていればそんな効果はほとんどないであろうことはわかるし、アップルも公式に否定している。)
ところが世の中は不条理なもので、アプリを強制終了したがる人たちがいる。それでそういう人たちが、「強制終了に手間がかかりすぎる」などと文句を言う。そのせいかどうかわからないが、次のiOS12ではアプリのカードを上に弾くだけで強制終了してしまう、iOS 6から10までの仕様に戻るらしい。
まったく困ったものである。この仕様のせいで、いったい何回、アプリを切り替えようとして不意にアプリが強制終了されたかわからない。
基本的に、同じ画面の同じ箇所から指を滑らせる操作では、縦の動きと横の動きに違う操作を割り当てるべきではない。片方のみに機能を割り当てて、もう片方は無割り当てが理想だが、それでも両方に割り当てるなら、非破壊的な機能でなければならない。例えばホーム画面では横スクロールの他に、縦にスワイプするとSpotlightが出てくるが、これは非破壊的だからまだマシだ。アプリの強制終了は、例えば何かの処理中だった場合に破棄されてしまうし、そうでなくても次回起動した時に前回の画面から再開できなくなる。
Appleも悪いが、とにかく、なぜかアプリをやたらと強制終了したがる人たちを撲滅しなければならない。
Permalink |記事への反応(15) | 18:51
返金祭りで騒動を起こしたソーシャルゲームのサポートセンターとのやりとりがあまりにも酷いので、吐き出させて下さい。
何かと話題を振りまいたゲームですが、ユーザーありきのサービスであるはずがユーザー無視の最悪のサポート対応です。
※ソシャゲーに興味ない方は、あまり面白いものではないです。スルー推奨。※
以下に、ドラゴンクエストモンスターズ スーパーライト(以下当アプリ)のサポート担当とのやりとりを記します。
今回ドラクエの名を冠したソーシャルゲームということでかなりの期待と
今までのドラクエへのお布施という意味も込め、当アプリ、金のロトガチャに 15,000円近く課金しました。
ところが、2月に虚偽表示による返金騒動があり、私もアップルストアに返金依頼をしましたが、
アプリの運営事業者から保障がすでに成された、との理由で返金を断られました。
実際に、当アプリWEBサイトの告知で、アプリ内通貨であるジェムでの保障があったとアナウンスがありましたが、
私のiPhone5 (当時ios 6 →現在7.1) では、アプリのタイトル画面から次の画面に遷移する際に、
「通信に失敗しました」というエラーが延々と出て次の画面に進めない現象があり、ジェムの受け取りが確認できていませんでした。
以下、私と「ドラゴンクエストモンスターズ スーパーライト」運営事務局サポート担当者(以下サ)のやりとりです。
私:今回の虚偽表示を受け、アップルストアに返金を希望したが、運営事業者と直接やりとりをしてくれとのことで断られた。返金を希望します。
5.6 返金不可法令により認められる場合を除き、ユーザーは未使用のバーチャルコインについて返金を受けることができないものとします。
上記より、返金はできません。
私:返金できないのは理解した。しかし「通信に失敗しました」とエラーがでて保障のジェムの確認ができない。
私:アプリを再インストールして、コードを入れて引継ぎをしたが、「通信に失敗しました」のエラーは変わらない。
そもそもこのエラーの原因はなんですか?
私:(アプリのインストールもできて、引継ぎもできて、アプリ内の更新ダウンロードまでできるのに、起動の時だけ「通信に失敗した」というのはおかしいだろ。)
サ:引継ぎコードを発行しました。再インストールして、コードを入れて下さい。
私:前回も同じことをして状況は改善されませんでしたが、今回実行すると治る保障はあるのですか?
そもそもエラーの原因も説明せずに、再インストールしろとは乱暴ではないのか?
サ:アプリをバージョンアップしましたので、改善されているかもしれないので再インストールして、引継ぎコードを入れて下さい。
私:アプリを再インストールして、コードを入れて引継ぎをしたが、「通信に失敗しました」のエラーは変わらない。
サ:OSバージョンが推奨環境を満たしていないことを確認いたしました。
つきましては、大変お手数ですがOSのバージョンを更新していただき、再度データ引き継ぎをお試しいただけますでしょうか。
私:いい加減な回答をしないで下さい。以前連絡した条件で、推奨環境を満たしているでしょう。
どうしてここまで滅茶苦茶な回答ができるんですか!ひどすぎます。こちらからのメール見てますか?
サ:ご連絡いただきました事象に関しましてお手数おかけしますが
私:(もはや再インストールの作業も、引継ぎコードの入力も、このやりとりもめんどくさい・・・)
今後どのように続けていかれるかは分かりませんが問題に対して原因を追求するような、
上記のやりとりも最終的に私からのメールを以って「問題は解決した」と考えているのかと思うと、大変腹立たしいです。
サポートセンターでありながらユーザーから提示された問題を解決もせず、ただマニュアル的に受け答えしているだけです。
また、終わるにしても、普通の会社のサポートセンターならば、ましてや自社が起こした問題ならば、ユーザーから「もういい」と連絡があったとしても、
原因調査しますので、もうしばらくお待ちいただけないか、とか、どうにもならない場合は、お力になれず申し訳ございませんでした、
このやりとりから私が感じた事は、どこの国の誰がやっているのか分からないような受け応えをサポートセンターが行っている現実は、
運営事業者の根底の考え方がユーザーを大切にしていない、ということに他なりません。
このようなものが長く続くとは思えないし、また、続いてほしくもないです。
私はこのアプリをおすすめしません。これからも色々な問題を起こすでしょう。
これからゲームを始めようと思われている方は思いとどまって頂き、現在プレイされている方は、運営事業者は
ユーザーのことなどこれっぽっちも思っていないことをご理解頂ければ、幸いです。
例のAppleのSSL/TLSのバグの件、日本語情報がなかったので意訳しました。
Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。
Apple'sSSL/TLSbug (22 Feb 2014)
https://www.imperialviolet.org/2014/02/22/applebug.html
(Hi Adam Langley, Thanyou foryourblog! We reallyappreciateyou.)
-----
昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。その答えは既にハッカーニュースのトップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。そして現在、俺たちはその誤った情報を正すステージに来ているんだ。ほらここに、Appleのbugがあるんだ。:
static OSStatusSSLVerifySignedServerKeyExchange(SSLContext *ctx,bool isRsa,SSLBuffer signedParams,uint8_t *signature, UInt16 signatureLen){ OSStatus err; ...if ((err =SSLHashSHA1.update(&hashCtx, &serverRandom)) !=0)goto fail;if ((err =SSLHashSHA1.update(&hashCtx, &signedParams)) !=0)goto fail;goto fail;if ((err =SSLHashSHA1.final(&hashCtx, &hashOut)) !=0)goto fail; ...fail:SSLFreeBuffer(&signedHashes);SSLFreeBuffer(&hashCtx);return err;}(Quoted fromApple's published source code.)
(訳者注:(Quoted fromApple's published source code)→sslKeyExchange.c)2行のgotoがあるだろ。2行目のgotoは、見て分かる通り常に発動する。変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。それって成功したのと同じなんだよね!この署名検証処理は(訳者注:SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージの署名を検証するものだ。このServerKeyExchangeでは、"the ephemeralkey"(通信のための一時的な鍵)を交換するためのDHE や ECDHE という暗号スイートが使われる。そのサーバーは言うんだ。「ここに"the ephemeralkey"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね!」今、もし"the ephemeralkey"と証明書の関係が破たんしているならば、すべては無意味なんだ。これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った(つまり適当にその辺で作った)鍵を使ったり、そもそもハンドシェイクに署名しなかったりってことができるってことなんだよ!そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵の秘密鍵を持っているってことの証明が、何もないんだ。これはSecureTransport(というライブラリ)に入っていて、以下に影響する。・iOS 7.0.6より前(俺は7.0.4で確認した)・OS X10.9.2より前(10.9.1で確認した)(訳者注:つまりiOS 7.0.6、OS X10.9.2で解決した)これはSecureTransportを使っているすべてに影響するけど、ChromeとFirefoxはそうじゃない。ChromeとFirefoxはSSL/TLSのためにNSSを使っている。でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね)超特急でテストサイトを作ってみたよ。https://www.imperialviolet.org:1266ポート番号に気を付けてね。(テストサイトはCVE番号になってるよ)443は通常通りに動いているからね。ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキーで署名しているんだ。君がもしポート1266のHTTPSサイトにアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:)それってつまり、証明書チェーンは正しいってことで、そしてハンドシェイクと証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。またこれは、DHE または ECDHE暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。攻撃者は、この暗号スイートを使うサーバーを自分で建てるようになるだろう。また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。でも攻撃者は使うプロトコルをある程度選ぶことができるから、安心できないよ。(訳者注:サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。)でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。(2つのうち、1つ目のほうがだいぶ好ましい。)俺のテストサイトでは、iOS 7.0.6 とOS X10.9.2で問題は解決していた。(更新:このバグはOS X10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。)こんなような微妙なバグって、悪夢だ。俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。ここに、今回の問題を明らかにするコードがある。:
externint f();int g() {int ret =1;gotoout; ret = f();out:return ret;}
もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeのGCC 4.8.2 やClang 3.3は死んでるコード(the dead code)について警告をしないんだ。本当にビックリだよ!!!ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。(ピーター・ネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない!)if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも)コードレビューはこの種類のバグについて効果的でありえる。ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。Appleのコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。でも、誰もがそんなにいい仲間を持てるわけじゃないよね。最後に。昨日、Appleが証明書のホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、それはOS X のコマンドラインでcurlを使うと、IPじゃない証明書でもIPでHTTPSにつながっちゃうってだけだったよ。変だけど。Safariはこの問題には関係なかったよ。
アラスカの国際空港で、アップルの地図アプリに従った運転者が滑走路に進入するという事件が連続して発生した。
「iOS 6」の地図アプリが、英国のロンドンでなく、カナダのオンタリオ州にあるロンドンに人々を誘導して不興を買ったことを覚えているだろうか。
アラスカの国際空港では、もっと大変なことが起きた。アップルの地図アプリに従ったドライバーが滑走路に進入するという事件が、連続して発生したのだ。
『Alaska Dispatch』紙が9月24日付けで掲載した記事によると、アップルの地図アプリは、東ランプ経由で誘導路B(BravoのB)に入るよう指示したという。これはパイロットが滑走路にアクセスするところだ。そこからだと、ターミナルは滑走路のすぐ向こう側に見えるので、ドライバーは、(通過したすべての道路標識を無視して)目に見える手がかりに従い、真っ直ぐターミナルに向かったという。
この出来事はまず9月6日に起こり、9月20日にもう一度発生した。Alaska Dispatch紙によると、最初の事件の後、アップルはこの問題に対処すると述べたという。しかしその後も、ハイヤーの運転手が、空港警備と警察によって包囲されて腰を抜かすという事件が発生した。現在は、問題が解決されるまで、一時的にバリケードが設置されているという。
弊社もAppbank様に多少なりレビューして頂いているので恩義はありますが、この頃Appbankのアホ記事がひどくなってきたのでまとめ。
ソフトバンクショップに掲載された「プラチナバンドって何のこと?」というポスター、このポスターは酷い誤りなのだが、知識のないAppbank @egaku氏が描いたおこちゃまの妄想絵。
「明日(7月25日)ソフトバンクで提供開始の「プラチナバンド」で何が変わるの? 」
http://megalodon.jp/2012-0730-1904-05/www.appbank.net/2012/02/29/iphone-news/377057.php
http://www.dotup.org/uploda/www.dotup.org3451711.jpg
参考
http://suzunonejh.blog15.fc2.com/blog-entry-2727.html
masason ご指摘感謝します。その様な間違ったポスターが2店舗確認できましたので即刻厳重注意し停止させます。 RT @Hiro_rea: ところで、こういうインチキ広告の撲滅に挑戦してみる気はありませんか?http://pic.twitter.com/3xBzM3bf
http://twitter.com/masason/status/229833694024695809
まずはこれで、ソフトバンクショップの信頼を失ったわけですね。
そして今日酷かったのはこの記事
「iOS 6のマップアプリの地図とGoogleマップの地図が異なる理由」
http://megalodon.jp/2012-0923-1651-57/www.appbank.net/2012/09/23/iphone-news/481548.php
参考
http://kabumatome.doorblog.jp/archives/65709956.html
inuro「ゼンリンの地図データを利用していないからです」それは違うぞ。あまりに浅すぎる記事に絶句。 / “iOS 6のマップアプリの地図とGoogleマップの地図が異なる理由 -iPhoneアプリのAppBank”
https://twitter.com/inuro/statuses/250029740596023297
あの会社は大学サークルの延長みたいなものなので、記事をチェック校正するエディタがいないのが原因なのだろうけど(もしエディタがいてこの記事を載せていたらそのエディタは速攻クビ)もう少し体系化できんのだろうか?これじゃアプリレビューも頼みたくない。