да без разницы

позволяет ли утилита pod узнать последнюю версию например snapkit?

pod outdated покажет устаревшие

cat Podfile.lock

Podfile.lock показывает текущую версию

которая установлена сейчас

ну

а тебе что надо

зайди на coсoapods и там посмотри какая последняя

$ pod outdated Analyzing dependencies The following pod updates are available: - GRDB.swift 0.103.0 -> 0.103.0 (latest version 0.106.1) - RxCocoa 3.3.1 -> 3.4.0 (latest version 3.4.0) - RxSwift 3.3.1 -> 3.4.0 (latest version 3.4.0)

Владимир все правильно понял

и да pod outdated правильное решение

показываеттекущие и можно ли их обновить и до какой версии

всем спасибо

еще подскажите пожалуйста

Error:(11, 8) module compiled with Swift 3.0.2 cannot be imported in Swift 3.1: /Users/mbp15/Library/Caches/AppCode2017.1/DerivedData/RenCredit-ejxjaruvyxwzordjxtuendhzqadz/Build/Products/Debug-iphonesimulator/SnapKit/SnapKit.framework/Modules/SnapKit.swiftmodule/x86_64.swiftmodule

это я как понимаю под не поддерживает текущую версию свифта?

Владимир все правильно понял

перед этим, наверное, надо будет выполнить pod repo update

или необязательно?

необязательно

outdated ессно сам полезен обновлять репу

пожалйста если кто знает, подскажите по ошибке выше

почистил derived data

запахало

на appcode

у них оказывается разные

народ. подскажите, строку (номер телефона) нормально хранить в юзер дефолтс или лучше создавать отдельный plist файл для таких целей

за юзердефолтс часто атата делали, поэтому использовал бы keychain

Отдельный plist точно не нужно. А для кейчейна имхо это не настолько приватная инфа

У меня наверно глупый вопрос, но это от неопытности... В коде есть #ifndef DEBUG Как мне установить приложение с DEBUG = NO на реальный девайс? Сейчас очевидно он = YES

#undef ?

У меня наверно глупый вопрос, но это от неопытности... В коде есть #ifndef DEBUG Как мне установить приложение с DEBUG = NO на реальный девайс? Сейчас очевидно он = YES

Ставишь 0 и устанавливаешь

define то все равно при этом останется

Ну значит временно удаляешь

Если там именно на наличие проверка

Вроде же человек разобрался давно

а в чем минус хранения в userDefaults? Помимо того, что plist уязвимы. Важную инфу я хрнаю в кейчене. Но нужно хранить пару строковых значений.

Ребят, скажите, что критично для написания тестов? Вот что нужно писать по TDD, а для каких моментов это трата времени? я и про unit и ui тесты хочу узнать

по мне так это бд, сервисный слой, работа с файлами и свои алгоритмы. Я что-то упустил? А для ui это кастомные какие-то компоненты

UI логика, если есть возможность.

Все что во ViewModel

Но это зависит от организации проекта

А кто-нибудь пробовал выкатить в аппстор приложение с поддержкой ios 9-10, а в следующем релизе с поддержкой ios 8-10?

А кто-нибудь пробовал выкатить в аппстор приложение с поддержкой ios 9-10, а в следующем релизе с поддержкой ios 8-10?

Ну не именно так, но бывало, опускали мин версию. Все ок

Ну не именно так, но бывало, опускали мин версию. Все ок

То есть эппл не реджекнет, если в одном из обновлений расширим список поддерживаемых осей?

То есть эппл не реджекнет, если в одном из обновлений расширим список поддерживаемых осей?

Нее, ну с чего бы. Главное чтобы работало на старых нормально. Хотя я не уверен, тестят ли они их так уж пристально

Нее, ну с чего бы. Главное чтобы работало на старых нормально. Хотя я не уверен, тестят ли они их так уж пристально

Ок, спасибо!

UI логика, если есть возможность.

а UI-тестами покрывать есть смысл каждый экран? Я просто не ивжу большого профита с этого?

пытаюсь сделать правильный TDD и вот такие вопросы...)

Если логика не сложная на экране, то может и не нужно

а UI-тестами покрывать есть смысл каждый экран? Я просто не ивжу большого профита с этого?

tdd предполагает сначала написание тестов а потом уже код но кто это делает? )

вот и срашиваю, у кого какой опыт был. Есть ли смысл все тетсить

в идеале разработчик покрывает код unit тестами на 50-80% (больше уже просто невозможно) + самостоятельно старается протыкать свой продукт после этого он сдает это дело отделу тестирования, где ребята со своим подходом смотрят на программу, тестируют ее. Если проект долгосрочный, то пишут тест кейсы, на основе которых потом пилят авто тесты (в том числе и UI)

но это в идеале

обычно так разработчик делает как можно быстрее, смотрит чтобы работало на основных действиях, потом быстро выливает тестировщикам, те тоже шустро все проверяют (если повезет, то что-нибудь успевают записать для отчетов). После чего сдают продукт достаточно проверенный, но с потенциальными дырками

//tdd - зло. Особенно в мобильной разработке

//tdd - зло. Особенно в мобильной разработке

почему?

послушайте подкаст Радио-Т (выпуск 536) очень годный подкаст в целом, а тут еще и доступно рассказывают почему TDD у хорошего разработчика должно вызывать рвотный позыв

http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565

tdd предполагает сначала написание тестов а потом уже код но кто это делает? )

Это если test first

парни? скажите пожалуйста а есть ли open source проекты которые можно глянуть? ну написанные на свифте соответственно, если есть - киньте ссылки пожаулйста на репозиторий где он лежит

лол

seriusly?

держи

http://bfy.tw/BQb7

та гуглится swift awesome projects например

а давно на убунта со свифтом подружилась?

в смысле?

https://github.com/apple/swift

рад за орлов

это очень важно, держи меня в курсе

чувак, я вопрос задал, а не открытие произвел

разницу прочувствуй и ответь

ясно

не трогай говно...

мамке пожалуйся

а давно на убунта со свифтом подружилась?

С тех пор как компилятор у свифта llvm, и с той поры когда он есть в виде deb-пакета

лет с 10 перестал. сразу после того как забыл фразу "а он первый начал"

Где можно набрать 500 пользователей?

А тому меня завтра встреча с инвесторами ))