ARKit ile ARCore arasında seçim yapmıyorsunuz; ikisini birden hedefliyorsanız hangi özelliğin iki platformda da çalıştığına karar veriyorsunuz. Karar tek bir soruya iniyor: uygulamanız kullanıcının bulunduğu yerin gerçek koordinatını bilmek zorunda mı, yoksa yalnızca önündeki yüzeyi mi tanıması gerekiyor?
İkinci durumda ortak payda geniş ve tek kod tabanı gerçekçi. Birinci durumda Google'ın Geospatial API'si karşılığı olmayan bir yetenek sunuyor ve mimariniz asimetrik oluyor. Bu yazı iki platformun 2026'daki gerçek durumunu, tarayıcı tarafındaki sert sınırı ve telefonun yetmediği yerde başlık sınıfı cihazda neyin değiştiğini anlatıyor.
ARCore: güncel sürüm ve yayılım rakamı
ARCore SDK for Android'in güncel sürümü v1.56.0. Bu sürümle targetSdkVersion Android API 37'ye yükseltildi ve iki yeni API eklendi: AcquireDepthImageMeters ve AcquireRawDepthImageMeters. Google'ın gerekçesi açık: derinlik verisini metre cinsinden float olarak sunarak ARCore ile OpenXR arasındaki veriyi birleştirmek. Yani derinlik verisi artık platformlar arası taşınabilir bir birimde.
Cihaz yayılımı konusunda Google'ın kendi yayımladığı tek rakam şu: Mayıs 2026 itibarıyla aktif cihazların %88'inden fazlası Depth API'yi destekliyor. Bu, derinlik tabanlı oklüzyonu (sanal nesnenin gerçek nesnenin arkasına geçmesi) artık isteğe bağlı bir süsleme değil, beklenen bir davranış hâline getiriyor.
Cihaz listesi dört kategoriye ayrılıyor: Android emülatörler (x86/x86_64 AVD, Android 8.1+), Android (Google Play), Android (Play Store'suz Çin cihazları) ve iOS (ARKit uyumlu, iOS 12.0+). Uygulama manifesti tarafında iki eşik var: "AR Optional" uygulamalar minSdkVersion 19 ve üzeri, "AR Required" uygulamalar 24 ve üzeri beyan etmek zorunda.
Listede kolayca gözden kaçan bir not var: bazı cihazlar için "Does not support Geospatial API" işareti düşülmüş. Yani Geospatial desteği ARCore desteğiyle eşanlamlı değil. Konum tabanlı bir deneyim kuruyorsanız hedef cihaz listenizi bu filtreyle ayrıca kontrol edin, aksi hâlde ARCore çalışan ama uygulamanız çalışmayan cihazlarla karşılaşırsınız.
Geospatial API: karşılığı olmayan tek yetenek
ARCore'un Geospatial API'si, Google Earth 3D modellerini ve Google Maps Street View görüntülerini kullanarak küresel ölçekli, konum tabanlı AR sağlıyor. Temel API'ler Earth.createAnchor() (enlem, boylam, rakım ve yönelim ile) ve GeospatialPose.
Bu, GPS'ten farklı bir şey. GPS size birkaç metre hassasiyetinde bir koordinat veriyor; VPS (Visual Positioning System) kameradan gelen görüntüyü referans veriyle eşleştirerek konumu ve yönelimi çok daha hassas belirliyor. Bir binanın cephesine sanal bir tabela yerleştirmek, GPS ile yapılamıyor.
Ürün kararı açısından sonucu şu: şehir ölçeğinde konumlu AR planlıyorsanız, Android tarafında Geospatial API ile başlayıp iOS tarafını nasıl çözeceğinizi ayrıca planlamanız gerekiyor. Bu, "tek kod tabanı" planını bozan gerçek bir asimetri.
Apple tarafı: SceneKit'ten RealityKit'e geçiş
Apple'ın 3D çatısı konusunda yön değişti. WWDC25'te "Bring your SceneKit project to RealityKit" başlıklı bir oturum yayımlandı (Session 288) ve Apple RealityKit'i SceneKit'in yerine geçecek çerçeve olarak konumlandırıyor. Yeni bir projeye SceneKit ile başlamak artık savunulabilir bir karar değil.
visionOS tarafında ARKit farklı çalışıyor ve bu ayrımı bilmek kapsam belirlemede işe yarıyor. visionOS'ta ARKit ve RealityKit işletim sistemine derin entegre; izleme ve sahne anlama bir sistem servisi olarak çalışıyor. visionOS'ta ARKit uygulamaya HandTrackingProvider ile el iskelet verisi sağlıyor; iOS ARKit'te bunun karşılığı yok. Nesne izleme (object tracking) ise her iki platformda çalışıyor ve referans nesneler yeniden eğitim gerektirmeden iki platformda da kullanılabiliyor (bkz. WWDC24 Session 10100).
İki platform aynı adı taşıyan iki farklı ürün: iOS'ta ekran üzerinden pass-through AR, visionOS'ta ellerle doğrudan etkileşimli immersif deneyim. Bir iOS AR uygulamasını visionOS'a taşımak bir derleme hedefi eklemekten ibaret değil, etkileşim modelini yeniden tasarlamak.
Sceneform öldü; hâlâ arayan varsa
Bu, eski eğitim içeriklerinin yaşattığı bir hayalet. Google'ın Sceneform Android SDK deposu 28 Temmuz 2020'de arşivlendi ve salt okunur durumda; README'de "Archived - This repository has been archived and is no longer maintained" yazıyor.
2019-2021 arası yazılmış Türkçe ve İngilizce AR eğitimlerinin çoğu Sceneform anlatıyor. Bir ekip üyesi "Sceneform ile yapalım" diyorsa, altı yıllık bir kaynaktan okuyor demektir.
Unity AR Foundation: iki platformu tek API ile hedeflemek
Her iki platformu da hedefleyecekseniz ve 3D içerik ağırlıklı bir uygulama kuruyorsanız, doğal seçim Unity AR Foundation. Güncel paket sürümü 6.6 ([email protected]). ARCore tarafında Unity 6 ve AR Foundation 6 için tam destek, ARCore v1.48.0 ile geldi; aynı sürümde iOS 13.0 altı desteği kaldırıldı.
AR Foundation'ın mantığı, ARKit ve ARCore'un kesişimini soyutlamak. Bu hem avantajı hem sınırı: ortak yetenekler (düzlem algılama, ışık tahmini, yüz izleme, görüntü izleme) tek API ile geliyor, ama platforma özgü yetenekler (Geospatial API, visionOS el izleme) için yine native koda inmeniz gerekiyor.
Karar kuralı:
| Durum | Seçim |
|---|---|
| Mevcut bir mobil uygulamaya küçük bir AR özelliği eklenecek | Native (ARKit + ARCore). Unity çalışma zamanını uygulamaya gömmek boyut ve karmaşıklık getiriyor. |
| Uygulama ağırlıklı olarak 3D içerik ve etkileşim | Unity AR Foundation |
| Şehir ölçeğinde konumlu AR gerekiyor | Android öncelikli (Geospatial API); iOS'u ayrı planlayın |
| Kullanıcı uygulama indirmeden denemeli | Aşağıdaki WebXR bölümünü okuyun; plan değişecek |
| Deneyim kullanıcının odasını anlamak zorunda | Başlık sınıfı cihaz; telefon AR'ı sahne modeli vermiyor |
WebXR: iOS Safari'de yok, ve bu çoğu planı bozuyor
"Uygulama indirmeden tarayıcıdan AR" fikri, pazarlama tarafında en çok istenen ve mühendislik tarafında en çok kırılan şey.
Tarayıcı destek verisi net: WebXR Device API'nin küresel kullanım oranı %77,15, ancak iOS Safari'de 3.2'den 27.2'ye kadar hiçbir sürümde desteklenmiyor. Chrome Android'de v152'den itibaren kısmi destek var; Firefox'ta 77-159 arası varsayılan kapalı; macOS Safari'de 13'ten Technology Preview'a kadar varsayılan kapalı.
Pratik sonucu şu: Türkiye'de iPhone kullanıcısına tarayıcıdan WebXR tabanlı AR deneyimi gösteremiyorsunuz. Kampanya sayfasına gömülü bir AR deneyimi planlıyorsanız iki seçenek kalıyor: iOS için AR Quick Look tabanlı bir yol (etkileşim sınırlı) ya da uygulama indirme.
Bu kısıtı proje başında söyleyin. Sonradan çıktığında kampanya takvimi kayıyor ve kimse geri dönüp "aslında WebXR iOS'ta yok" demiyor; bunun yerine bütçe uygulamaya kayıyor.
8th Wall'da barındırılan WebAR kampanyanız varsa, zemin 28 Şubat 2026'da değişti
iOS'taki WebXR boşluğunu yıllarca kapatan şey, kameradan gelen görüntüyü JavaScript tarafında işleyen ticari SLAM platformlarıydı ve bunların en yaygını 8th Wall'dı. O model sona erdi.
8th Wall'ın kendi açıklamasına göre barındırılan platform 28 Şubat 2026'da emekliye ayrıldı ve tüm ücretli abonelikler aynı tarihte sona erdi. Proje dışa aktarma özelliği de o tarihte kapandı. Bugün 8th Wall ücretsiz: hesap gerekmiyor, giriş yok, XR Engine ikili (binary) olarak dağıtılıyor ve dağıtılan motorun sınırlı kullanım lisansı altında ticari kullanıma izin veriliyor (bkz. 8thwall.org).
Karar açısından üç sonucu var:
- Eski bir kampanya linkiniz varsa bugün kendi elinizde değil. Barındırma artık sizde olmadığı için deneyimi kendi altyapınıza taşımanız gerekiyor; projeyi 28.02.2026'dan önce dışa aktarmadıysanız o yol da kapalı.
- Yeni proje için aylık lisans kalemi yok, işletme kalemi var. Bütçe artık abonelik değil; barındırma, HTTPS, CDN ve sürüm yönetimi sizin tarafınızda.
- Motor açık kaynak değil, ücretsiz. İkili dağıtım ve sınırlı kullanım lisansı, "kaynağını alıp değiştiririz" planını dışarıda bırakıyor. Tedarikçi bağımlılığı azaldı ama bitmedi.
2023-2025 arasında yazılmış WebAR karşılaştırmalarının neredeyse tamamı 8th Wall'ı aylık ücretli bir hizmet olarak anlatıyor. Bir teklifte hâlâ o kalem varsa, teklif eski.
Telefon yetmiyorsa: başlık sınıfı cihazda kurallar değişiyor
Telefon AR'ı ile başlık sınıfı karma gerçeklik arasındaki fark özellik listesi farkı değil, mimari farkı. Telefon uygulaması önündeki yüzeyi tanıyor; Quest sınıfı bir cihazda uygulama odanın modelini sorgulayabiliyor.
Meta'nın Scene belgesi bunu şöyle tarifliyor: Space Setup sonucunda üretilen scene model, fiziksel dünyanın indekslenebilir ve sorgulanabilir bir temsili. Temel birim scene anchor: anlamsal etiket (WALL gibi), düzlem boyutları, hacim ve scene mesh bileşenleri taşıyor. Erişim OVRAnchor API'si ile, önerilen üst katman ise Mixed Reality Utility Kit (bkz. Meta Horizon Documentation, Scene Overview).
Aynı belgede kapsamı doğrudan etkileyen üç sınır var:
- İşletim sistemi en fazla 15 oda tutabiliyor. Çok mekânlı bir kurumsal senaryo planlıyorsanız bu bir tavan.
- Uygulama, spatial data için uygulamaya özel çalışma zamanı izni istemek zorunda. Yani oda verisine erişim kullanıcı onayına bağlı ve reddedilebilir; reddedildiğinde çalışan bir yedek akışınız olmalı.
- Space setup, Link üzerinden yapılamıyor, cihaz üzerinde yapılmak zorunda. Bu, masaüstünden Link ile test eden ekiplerin döngüsünü doğrudan uzatıyor ve sprint planında hesaba katılmıyor.
Uygulama içinden sahne modelinin var olup olmadığını sorgulayıp gerektiğinde space setup'ı tetikleyebiliyorsunuz. İlk açılış akışını buna göre tasarlayın: kullanıcı odasını taramadan çalışmayan bir uygulamanın ilk kullanım deneyimi, tarama adımının kalitesi kadar iyi.
Kurumsal VR eğitiminde iş vakasını hangi rakamla kurmayacaksınız
VR eğitimi konusundaki Türkçe içeriklerin neredeyse tamamı aynı iki sayıyı tekrarlıyor: geleneksel eğitimde %10, VR'da %75 bilgi tutma. Bu sayıların birincil kaynağı yok. Öğrenme piramidi olarak dolaşan bu oranlar için atıf zinciri boş çıkıyor, ve bir yatırım kararını bunun üzerine kurarsanız ilk sorulduğunda savunamazsınız.
Doğrulanabilir tek büyük ölçek hâlâ Walmart'ın kendi duyurusu: ABD'deki tüm mağazalara 17.000'den fazla Oculus Go dağıtıldı, hedef kitle 1 milyondan fazla çalışan, içerik STRIVR ile üretildi ve 45'ten fazla modül vardı. Duyurunun tarihi 20 Eylül 2018 (bkz. Walmart Corporate Newsroom, "How VR is Transforming the Way We Train Associates").
Bu rakamı kullanırken iki şeyi birlikte söyleyin: ölçek gerçek, ama tarih sekiz yıl öncesi ve o donanım üretimden kalktı. Yani örnek "VR eğitimi ölçeklenebilir" tezini destekliyor, "şu kadar tasarruf edersiniz" tezini desteklemiyor.
Ölçülebilir bir iş vakası kurmak istiyorsanız kendi sayınızı üretin. Pilot için en ucuz kurulum, tek bir prosedür (yangın tahliyesi, makine kilitleme, tehlikeli madde) ve iki grup: aynı içeriği klasik yöntemle alan grup ile VR ile alan grup. Ölçtüğünüz şey bilgi tutma değil, hata sayısı ve prosedür tamamlama süresi olsun. Bunlar zaten iş güvenliği kayıtlarınızda var.
"Metaverse" kelimesini kapsam belgesinden çıkarın
Bu kelime bir teknoloji değil bir pazarlama şemsiyesi ve kapsam belgesinde geçtiğinde her zaman aynı soruyu gizliyor: kullanıcı nerede, hangi cihazda, kaç kişiyle aynı anda?
Üç somut soru kelimenin yerini alıyor:
- Deneyim kalıcı mı, yani kullanıcı çıktığında durum saklanıyor mu?
- Eşzamanlı mı, yani birden fazla kullanıcı aynı anda aynı sahneyi mi görüyor?
- Kullanıcı bir ekonomi mi kuruyor, yani satın alınan bir şey mi var?
Üçüne de hayır diyorsanız istediğiniz şey bir 3D ürün görselleştirmesi ve bütçesi bambaşka.
Eşzamanlılığa evet diyorsanız proje bir AR projesi olmaktan çıkıp ağ projesine dönüşüyor: çapa senkronizasyonu, durum çözümleme ve gecikme bütçesi ana kalemler hâline geliyor. Bu, kapsamı en hızlı büyüten tek cevap.
Kapsam çıkarırken sorulacak beş soru
AR projelerinde teklif ile gerçek arasındaki farkı üreten şey neredeyse her zaman aşağıdaki beş sorunun cevaplanmamış olması:
- Nesne mi yüzey mi? Masaya sanal bir mobilya koymak (düzlem algılama) ile belirli bir fiziksel ürünü tanımak (nesne izleme) arasında ciddi bir efor farkı var.
- Kapalı alan mı açık alan mı? Açık alanda ışık tahmini ve izleme kararlılığı düşüyor; gölge ve yansıma kalitesi beklentiyi karşılamıyor.
- 3D varlıklar kimden gelecek? Bu, AR projelerinin en sık atlanan bütçe kalemi. Optimize edilmemiş bir CAD modeli mobil cihazda çalışmıyor; yeniden topoloji ve doku çalışması ayrı bir iş.
- Kaç kullanıcı aynı anda aynı sahneyi görecek? Paylaşımlı deneyim, çapa senkronizasyonu ve ağ katmanı demek.
- Hedef cihaz listesi ne? "AR Required" beyanı
minSdkVersion24 istiyor, Geospatial desteği evrensel değil ve başlık sınıfı cihazda 15 oda sınırı var.
Üçüncü soru genellikle projenin en büyük kalemi oluyor. Kendi kapsamınız için bir bant çıkarmak isterseniz proje fiyat hesaplama aracı işinizi görür.
Sırada ne var
Ürün fikrinizi tek bir testten geçirin: kullanıcıya hangi cihazda göstereceksiniz ve o cihazda tarayıcı mı, uygulama mı, başlık mı? İki cevabı yazdığınız anda yukarıdaki kısıtların hangisinin sizi bağladığı netleşiyor. iPhone ve tarayıcı yazdıysanız planı baştan değiştirmek zorundasınız; bunu keşfetmenin en ucuz zamanı şimdi.
AR ve VR tarafındaki çalışma biçimimizi AR ve VR çözümleri sayfasında, mobil tarafı mobil uygulama geliştirme sayfasında bulabilirsiniz. Çapraz platform çerçeve kararı için React Native ve Flutter karşılaştırmasına, kapsam görüşmesi için iletişim sayfasına bakabilirsiniz.
Bilgiler 25 Eylül 2026 tarihinde doğrulanmıştır: developers.google.com/ar sürüm notları (ARCore SDK v1.56.0) ve desteklenen cihazlar sayfası, github.com/google-ar/sceneform-android-sdk arşiv durumu, caniuse.com WebXR destek tablosu, Apple WWDC25 Session 288 ve WWDC24 Session 10100, Unity AR Foundation 6.6 paket dokümanı, 8thwall.org platform durumu, Meta Horizon Documentation Scene Overview, Walmart Corporate Newsroom 20.09.2018 duyurusu. Apple'ın ARKit dokümantasyon sayfaları JavaScript ile üretildiği için ARKit sürüm numarası ve cihaz gereksinimleri sayısal olarak verilmemiştir. VR eğitimde sık tekrarlanan bilgi tutma yüzdeleri birincil kaynağa bağlanamadığı için kullanılmamıştır.
