Uma pergunta que vem batendo na porta dos desenvolvedores do mundo iOS: posso largar de lado Objective-C e estudar somente Swift para fazer meu app? A resposta é simples: sim!

No exato momento em que um programador, que agora podemos começar a chamar de “velha-guarda”, olhar essa minha afirmação, eu serei castigado pelas milhões de pragas do Egito, mas é uma afirmação correta e consciente. No decorrer do artigo você vai entender.

Apesar de querer começar por outro ponto, tenho que primeiro responder à pergunta “Swift não é beta, e por isso tem muitos bugs?”. Bom, isso provavelmente vem das pessoas que utilizaram o “beta beta” do Swift, quando ele foi apresentado. São dois tempos, aquele em que o Swift foi anunciado e, consequentemente, permitido àqueles que têm cadastro como desenvolvedor usarem, e o momento em que foi lançado o iOS 8, que permitiu o upload de programas inteiros escritos em Swift.

Na primeira versão, como tem que ser algo realmente beta, houve grandes mudanças. Tivemos bugs em tarefas simples, que retiraram, mudaram coisas e melhoraram, uma vez que era o momento propício para isso. Assim como há hoje no Node.js, que ainda não deixou de ser beta e já vi alterações que mudam a forma de fazer coisas simples. E no Bootstrap, que já fez alterações que os deuses do código quase vieram à Terra. Entenda esse momento e faça um balanço.

O segundo momento é a “permissão” para realmente lançarmos app em Swift, e de lá para cá tivemos algumas muitas melhorias. Lembre-se, seu código de nenhuma maneira foi prejudicado ou alterado (com exceção da adição recente do optional para a propriedades – que não vou explicar agora o porquê, mas isso só veio para fortalecer os pilares do Swift). Logicamente, como “todas” as outras linguagens que comentei fazem, a ideia é ter uma ferramenta “upgrade” para somente adicionar o que estava faltando. É uma linguagem forte, que vem evoluindo a partir do seu real lançamento, e vai continuar assim. Se você não concorda com isso, melhor parar por aqui. Mas espero que tenha lido o livro que a Apple fez sobre a linguagem. Lá eles falam exatamente isso.

Qualquer programador Objective-C já ouviu milhões de reclamações a respeito da linguagem e da maneira de se fazer as coisas. A única forma da Apple ouvir isso e realmente fazer alguma coisa, seria alterar toda a estrutura da linguagem. Me diz, se você é um desenvolvedor, isso é uma boa ideia?! Por que não construir uma linguagem moderna e de fácil visualização como a maioria das linguagens de script? E o melhor disso, que eu possa utilizar as duas ao mesmo tempo sem nenhum problema?!

Vamos analisar rapidamente um exemplo da linguagem em Objective-C, algo básico como um método recebendo parâmetros e chamando esse método:

@interface ViewController ()
 
@end
 
@implementation ViewController
 
- (void)viewDidLoad {
    [super viewDidLoad];
 
    [self meuMetodoPrimeiroParametro:@"Teste" quantidade:4];
    
}
- (NSDictionary*)meuMetodoPrimeiroParametro:(NSString*)parametro quantidade:(int)qnt{
    
    NSDictionary* dict = [[NSDictionary alloc] initWithObjectsAndKeys:parametro,[NSNumber numberWithInt:qnt], nil];
    
    NSLog(@"%@", dict);
 
    return dict;
}
 
@end

Uau, quanta coisa! Coloquei um NSLog() ali no meio só para podermos olhar o que foi impresso no terminal sem colocar breakpoint. Pontos relevantes a considerar ao fazermos em Swift: nome e tamanho do método, tipo de parâmetro, como inserir itens objetos em um dicionário, retorno do método e, claro, como eu chamo um método estando na mesma classe.

Agora como fazer a mesma tarefa em Swift:

class ViewController: UIViewController {
 
    override func viewDidLoad() {
        super.viewDidLoad()
    
        meuMetodo("Teste", quantidade: 4)
    }
 
 
    func meuMetodo(parametro:String, quantidade: Int) -> Dictionary<Int,String>{
        
        var dict = [quantidade:parametro]
        
        println(dict)
        
        return dict
    }
 
 
}

Podemos perceber que visualmente a diferença é gritante. Pelo modo de imprimir no console usei somente “println(dict)” e pronto! Ele imprimiu, sem mais delongas. Para criar meu dicionário, eu não fiz nenhuma forma mais breve do Swift para isso; é literalmente o que eu mostrei: criei um dicionário. E ainda tem maneiras mais simples, se você visse como adicionar itens novos, por exemplo, iria ao êxtase.

Agora vamos a uma coisa importante: eu coloquei como parâmetro de propósito um tipo primitivo Int nos dois exemplos, mas para você fazer isso em Objective-C o NSDictionary precisa aceitar somente objetos. Em Swift, Int é int mesmo e pronto; não importando ser primitivo ou objeto, que seria um NSInteger em Objective-C, por exemplo. Finalmente, viu como chamamos nosso método?!

Claro que esse foi um exemplo simples, mas esses são alguns pontos que eu considero relevantes durante o desenvolvimento:

• Legibilidade
• Verbosidade
• Agilidade
• Facilidade

Parece um pouco estranho, mas não é. Quer dizer que a partir de agora eu não gosto de Objective-C e adotei Swift? Sim e não. Ainda adoro Objective-C – não pense que você quando começar a subir o nível de dificuldade irá conseguir resolver seus problemas somente sabendo Swift. As pessoas vêm há alguns anos resolvendo em Objective-C e você precisará ler, entender e saber interpretar. Mas além desse pequeno exemplo, existem alguns muitos outros que nos dirão o quanto a linguagem é poderosa. Há um caminho que será sem sombra de dúvida adotado pela Apple e é Swift. Por isso, estou sim adotando Swift, assim como a comunidade, pegando projetos e problemas que tive em Objective-C e fazendo em Swift.

Na minha experiência foi tão simples quanto escrever em Objective-C. Por que? Porque eu estou fazendo o mesmo que em Objective-C, mas com a “tradução” em Swift. Fiz de maneira mais simples, isso posso garantir.

Então é isso, pode sim começar seu aplicativo em Swift e ele não irá quebrar e não deixará de rodar. Pelo contrário, é garantido que irá permanecer por um longo, longo tempo. E use um de seus recursos mais impressionantes, o “Playground”.

Só para aqueles extremamente conservadores: posso pegar meu projeto em Objective-C e inserir classes em Swift e as classes “conversarão” normalmente uma com as outras. Pode até chamar métodos, usar delegates, e tudo o mais.

Concorda, discorda? Já começou a usar Swift e quer dar a sua opinião? Utilize os campos abaixo.

Nota do editor: Tivemos um Hangout interno aqui na Concrete Solutions na semana passada sobre o assunto e a conclusão é a de que, no ambiente corporativo, precisamos de uma transição. Alguns preferem esperar o lançamento do XCode 6.3 ou maior, com suporte oficial ao Swift 1.2, e outros preferem ver problemas específicos solucionados antes de usar a linguagem para projetos de clientes. Por isso, a nossa conclusão como empresa é a de que é preciso estudar a linguagem e ir usando aos poucos antes de adotá-la como oficial. Para quem quer aprender, o pessoal aqui indica este curso da Stanford sobre o assunto. Para uso pessoal e para “hobby”, porém, todos concordam que é uma ótima linguagem, pode e deve ser usada. Só enfrenta alguns problemas que todo algo muito novo tem.